11:20 a.m.
Hi Guillaume.
The trouble with the way it used to work is that we are essentially looking
at tables from all catalogs/schemas. That is the difference between "" and
null in those DBMD params. This causes problems in a few different
situations. First is the case of simply having more than one table with
the same name in different catalogs/schemas. The other is the case of
Oracle synonyms. In both cases we get back multiple results for tables
with a given name if we do not account for catalog/schema.
Bottom line is that neither schema validation nor schema update were
previously supported. I am trying to change that, but part of that means
fixing oddities like this.
That said... there are a few things you could do within the changes. You
could simply tell Hibernate via Dialect#getNameQualifierSupport that
neither catalog nor schema are supported for your db; just return
NameQualifierSupport#NONE.
This will effectively make Hibernate use null rather than "" in these DBMD
calls.
The other thing you could do relates to a task I have for myself.
Basically I would like to
make org.hibernate.tool.schema.extract.spi.InformationExtractor
configurable. This is the thing where you are seeing the calls into
NormalizingIdentifierHelperImpl.toMetaDataSchemaName. It is the thing that
talks to the database to extract the schema information (tables, sequences,
columns, etc). Andrea is in the middle of refactoring this contract at the
moment, but you can at least see its intent; after his work there will no
longer be plural forms to these methods. As you can see from my comments
where this gets constructed, I planned to make that pluggable. I just have
not gotten to that yet. If you want to work on that, that would get it
done faster. I plan the next release next week so its becoming time
critical for 5.0.
As for your comment about AvailableSettings.DEFAULT_SCHEMA I don't
understand.
On Tue, Jun 16, 2015 at 6:02 AM Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
FWIW, if I change the return ""; to return null;, I get my
application to
start \o/.
I'll start testing the application more in depth.
FWIW, I don't know if it's something normal but
AvailableSettings.DEFAULT_SCHEMA is not used in the constructor of
JdbcEnvironmentImpl used when JDBC is available (I first tried to fix the
issue by using this setting).
On Tue, Jun 16, 2015 at 12:24 PM, Guillaume Smet <guillaume.smet(a)gmail.com
>
wrote:
> Hi,
>
> Still trying to get one of our applications starting with ORM 5. With
> Search 5.4.0.Beta1 and Spring 4.2.0.RC1, I'm now at the database schema
> validation phase.
>
> I think there's something fishy with the way a table is looked for when
> we're using specific schemas in our database.
>
> Some background: we use PostgreSQL, we remove the public schema and we
> create a schema which is the default schema for the user.
>
> Our Hibernate app doesn't know anything about the schema and it used to
> work fine with ORM 3 and 4.
>
> We like this configuration as the schema used is totally transparent for
> the application and we can play with it at the database level without
> changing the Hibernate configuration.
>
> The fact is that it doesn't work anymore with ORM 5. The problem is that,
> when the schema is null, ORM now considers that the schema should be ""
> (empty string) if we haven't set a default schema at the JDBC level. This
> leads to trying to find the tables in the "" schema which obviously
fails.
>
> AFAICS, it's something specifically wanted as in
> NormalizingIdentifierHelperImpl.toMetaDataSchemaName, we have the
following
> lines:
> if ( identifier == null ) {
> if ( jdbcEnvironment.getCurrentSchema() == null ) {
> return "";
> }
> identifier = jdbcEnvironment.getCurrentSchema();
> }
>
> IMHO, in the null case, if the current schema isn't specified, we should
> return null and let the database determine which schema to use instead of
> deciding that the schema is "".
>
> If it's null, the schema filter will not be considered and the schema
> resolution will be let to the database.
>
> Any thoughts?
>
> --
> Guillaume
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev