[hibernate-dev] More Dialect and quoting fun

Max Rydahl Andersen manderse at redhat.com
Wed May 27 06:23:19 EDT 2015

On 27 May 2015, at 5:49, Steve Ebersole wrote:

> 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.

I reckon your issue is that you need access to Dialect before you might
have a DatabaseMetaData so you can't give that to the Dialect to hold on 
to ?

Thus having some parameter to Dialect that allows access to 
would be most sensible I would think.

One concern about DatabaseMetaData that hit the tools a few times is 
getting this can be extremely expensive for some drivers (I don't recall 
exactly, but Oracle comes to mind ;)

Thus if you do add it as a parameter to Dialect calls, it might be worth
proxying or wrap DatabaseMetaData. Also be aware that DatabaseMetaData 
actually *require* a connection to a database which is not optimal
for tools that might want to just get a script generated without 
full access to a database.


> 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?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


More information about the hibernate-dev mailing list