[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:
> 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
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>
>> What follows is solely an issue with schema update and schema
>> 2 tools that to date we have not "really" supported, but I am trying
>> 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
>> * 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
>> used when extracting values from the results. We currently rely on
>> 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
>> auto-quoting. For that, we defined a
>> Dialect#determineKeywordsForAutoQuoting method and allowed Dialects
>> 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
>> Dialect#determineKeywordsForAutoQuoting and instead define a
>> Dialect#buildIdentifierHelper method. This could work one of 2 ways.
>> First, the Dialect#buildIdentifierHelper method accepts a
>> 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
>> first route would mean each Dialect impl that wants to override this
>> having to handle nulls there. Not ideal.
>> A second approach would be to have Dialect#buildIdentifierHelper
>> either no parameters or just one parameter which would be the same as
>> is passed to Dialect#determineKeywordsForAutoQuoting. This would
>> work such
>> that null returned from this method would mean to use a fallback
>> based on DatabaseMetaData.
>> What do y'all think?
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev