Dialect#defaultProperties is a broken concept IMO. It was an attempt to
avoid an explosion of methods such as the one you propose. I personally
agree that the specific methods are better.
However, all that said.. I do not believe what you say is accurate. At
least not looking at the code. In SessionFactoryOptionsStateStandardImpl
we build a Map of settings as follows:
1) apply Dialect#defaultProperties
2) apply user settings over top of that
So the user's setting should override the Dialect default. That's how
settings should always work - something a user explicitly sets in their
config should always have precedence. Are you seeing a case where that
does not happen as described?
Also, to clear up a misnomer... we don't "change the environment setting".
That's not how SessionFactoryOptionsStateStandardImpl and the config map
building works.
On Mon, Feb 8, 2016 at 11:58 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
Hi,
While browsing the PRs on GitHub, I stumbled on this issue:
https://hibernate.atlassian.net/browse/HHH-10290
In the current implementation, the hibernate.jdbc.batch_versioned_data
property is set to true and
we override it at Dialect-level as follows:
public Oracle12cDialect() {
super();
getDefaultProperties().setProperty( Environment.BATCH_VERSIONED_DATA,
"true" );
}
Wouldn't it be better if the Dialect had a methods like:
boolean supportsBatchVersionedData();
and we wouldn't change the environment setting?
With this method added, the user can override the Dialect setting using the
environment variable.
With the current implementation, we always override that setting.
Vlad
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev