[hibernate-dev] More Dialect and quoting fun

Steve Ebersole steve at hibernate.org
Tue May 26 23:29:11 EDT 2015


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?


More information about the hibernate-dev mailing list