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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev