<LongStreamOfRandomThoughts>
Steve Ebersole, I get the point about why you tried to keep DialectResolver/DatabaseMetaDataDialectResolver around for delegation in
HHH-7965
. However, like you mentioned today, at a low level we now rely on DatabaseInfoDialectResolver (JPA schema gen, possibly other areas that do not have access to the connection, etc.). If that's the case, what's the point of supporting DatabaseMetaDataDialectResolver at all? StandardDatabaseMetaDataDialectResolver simply punts to the DatabaseInfoDialectResolver currently.
Do we really want users to be able to supply their own DatabaseMetaDataDialectResolver? Are there situations where a user would supply a DatabaseMetaDataDialectResolver, but not a DatabaseInfoDialectResolver, and expect resolving to work correctly/consistently across the framework? Realistically, shouldn't they be providing a DatabaseInfoDialectResolver anyway? IMO, a mix and delegation pattern doesn't quite make sense.
IIUC, the only thing that uses DialectFactory or DatabaseMetaDataDialectResolver is JDBCServices, but that could certainly be using DatabaseInfoDialectResolver instead.
</LongStreamOfRandomThoughts>
|