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 <st...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev /max http://about.me/maxandersen _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
