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
