[hibernate-dev] 6.0 - Dialect "initialization" proposal

Steve Ebersole steve at hibernate.org
Fri Jun 16 11:18:54 EDT 2017


Another change that has been discussed for a long time has been adding the
ability for Dialects to initialize themselves (or some "environment"
delegate) based on database/driver info including version info.  The idea
would be to get out of having to define new Dialects just for some minor
update in a database or driver that Hibernate needs to be aware of - the
Dialect would be allowed to make that distinction itself based on access to
this info.

As hinted above, I am not sure yet if the best approach to this is to have
the Dialect configure itself (least disruptive) or have it configure some
"environment" (an expanded JdbcEnvironment maybe).  But regardless, the
idea is the same.

The proposal centers around 2 contracts:

   1. Dialect itself and some "Dialect#initialize" method
   2. A way to give Dialect#initialize access to the needed information.

Let's start with (2) as it is the more defined.  The basic idea would be
similar to the existing
`org.hibernate.engine.jdbc.dialect.spi.DialectResolutionInfo` contract.
The initial idea is something like
https://gist.github.com/sebersole/5af5bc5456701054632dd0eb65403505

For (1) there is still the question of whether Dialect#initialize affects
the Dialect itself or generates some "environment" object.  But assuming
that it affects the Dialect itself, we would have something as simple as:

    DatabaseInformation dbInfo = resolveDatabaseInformation(...);
    Dialect dialect = resolveDialect( dbInfo );
    dialect.initialize( dbInfo );

Or if we decide it should produce an environment object, something like:

    DatabaseInformation dbInfo = resolveDatabaseInformation(...);
    Dialect dialect = resolveDialect( dbInfo );
    TheEnvironment env = dialect.initialize( dbInfo );

To note, we pass DatabaseInformation into #resolveDialect because it needs
some of that info (database-name / driver-name mainly) to decide on the
Dialect.

The end game here is that we would have single Dialects per database.  E.g.
we'd have just:

   1. OracleDialect

instead of:

   1. OracleDialect
   2. Oracle8iDialect
   3. Oracle9Dialect
   4. Oracle9iDialect
   5. Oracle10gDialect
   6. Oracle12cDialect
   7. ...


More information about the hibernate-dev mailing list