[hibernate-dev] More Dialect and quoting fun
steve at hibernate.org
Tue May 26 23:49:41 EDT 2015
If anyone is interested, the issue is here:
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 <steve at hibernate.org>
> 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
> * 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?
More information about the hibernate-dev