[hibernate-dev] More Dialect and quoting fun

[Max Rydahl Andersen]

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 
DatabaseMetaData
would be most sensible I would think.

One concern about DatabaseMetaData that hit the tools a few times is 
that
getting this can be extremely expensive for some drivers (I don't recall 
which
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 
might
actually *require* a connection to a database which is not optimal
for tools that might want to just get a script generated without 
requiring
full access to a database.

/max

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


/max
http://about.me/maxandersen