10:18 a.m.
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. ...
10:46 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:10 p.m.
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(a)hibernate.org>
wrote:
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
2747
days inactive
2747
days old
2 comments
2 participants
participants (2)
-
Sanne Grinovero -
Steve Ebersole