[hibernate-dev] More Dialect and quoting fun

Steve Ebersole steve at hibernate.org
Tue May 26 23:49:41 EDT 2015


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 <steve at 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?
>


More information about the hibernate-dev mailing list