If anyone is interested, the issue is here: https://hibernate.atlassian.net/browse/HHH-9820
I do wonder overall about the interplay that should happen between a Dialect and the JdbcEnvironment. On Tue, May 26, 2015 at 10:29 PM, Steve Ebersole <st...@hibernate.org> wrote: > What follows is solely an issue with schema update and schema validation, > 2 tools that to date we have not "really" supported, but I am trying to > change that with 5.0. > > We discussed before the idea of auto-quoting and who should be the > authority in regards to keywords. We decided that it would be Dialect, for > Dialects that chose to do it, rather than the JDBC DatabaseMetaData. > However there is another piece to this that we currently miss. It has to > do with the following methods: > > * java.sql.DatabaseMetaData#storesMixedCaseQuotedIdentifiers > * java.sql.DatabaseMetaData#storesLowerCaseQuotedIdentifiers > * java.sql.DatabaseMetaData#storesUpperCaseQuotedIdentifiers > * java.sql.DatabaseMetaData#storesMixedCaseIdentifiers > * java.sql.DatabaseMetaData#storesUpperCaseIdentifiers > * java.sql.DatabaseMetaData#storesLowerCaseIdentifiers > > We already have bug reports that come directly from drivers not > implementing these "properly". > > They come into play in the implementation of the following methods (on > org.hibernate.engine.jdbc.env.spi.IdentifierHelper): > > * toMetaDataCatalogName > * toMetaDataSchemaName > * toMetaDataObjectName > * fromMetaDataCatalogName > * fromMetaDataSchemaName > * fromMetaDataObjectName > > The to* methods are used when binding the Identifiers to the metadata > queries (DatabaseMetaData#getTables method e.g.). The from* methods are > used when extracting values from the results. We currently rely on the > answers to the referenced DatabaseMetaData methods to determine the > quoting->case conversion and case->quoting conversions. > > My proposal is that we go a step further than what we did for Dialect and > auto-quoting. For that, we defined a > Dialect#determineKeywordsForAutoQuoting method and allowed Dialects to > override it if they wanted. The only time that method is used actually is > in building the IdentifierHelper instance. So my proposal is that we drop > Dialect#determineKeywordsForAutoQuoting and instead define a > Dialect#buildIdentifierHelper method. This could work one of 2 ways. > > First, the Dialect#buildIdentifierHelper method accepts a DatabaseMetaData > and the base implementation would do what we do today. However, > DatabaseMetaData can very well be null. When we initialize > IdentifierHelper atm we assume some (H2 based) defaults. So going this > first route would mean each Dialect impl that wants to override this method > having to handle nulls there. Not ideal. > > A second approach would be to have Dialect#buildIdentifierHelper accept > either no parameters or just one parameter which would be the same as what > is passed to Dialect#determineKeywordsForAutoQuoting. This would work such > that null returned from this method would mean to use a fallback approach > based on DatabaseMetaData. > > What do y'all think? > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
