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

Steve Ebersole steve at hibernate.org
Fri Jun 16 14:10:54 EDT 2017

Dialect *can be* immutable.  That's the point of whether this process
"affects the Dialect itself or generates some "environment" object".

I'm not sure what you propose specifically is a great idea.  Here is why..
In your proposal, again using Oracle as example, we'd need
OracleDialectBuilder and OracleDialect.  At least that is the only
practical way I can see this work.  Correct me if I am missing something.

Given my understanding being accurate, I assume you'd see something like
this instead of what I posted:

    DatabaseInformation dbInfo = resolveDatabaseInformation(...);
    DialectBuilder dialectBuilder = resolveDialectBuilder( dbInfo );
    Dialect dialect = dialectBuilder.initialize( dbInfo );

Again, if I am misunderstanding help me understand.

Additionally, while this still cuts down on the number of classes
specifically for Oracle it adds another class for all the others for which
we only have 1 - we'd now need 2, the builder and the dialect.

On Fri, Jun 16, 2017 at 10:47 AM Sanne Grinovero <sanne at hibernate.org>

> 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, <steve at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

More information about the hibernate-dev mailing list