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