Could we have a way to configure a "dialect builder" (or factory) instead?
I'd love to have dialects immutable. On Fri, 16 Jun 2017, 17:33 Steve Ebersole, <st...@hibernate.org> wrote: > 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. ... > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
