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