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&gt; 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 >