Re: [hibernate-dev] 5.0 defaults
On 08/03/2015 02:17 PM, Steve Ebersole wrote:
Scott has been asking about making some setting defaults consistent
between
Hibernate and WildFly. Most I think WildFly should just use the ORM
defaults.
If ORM 5.0 used the same defaults as the WildFly (JPA) deployer, then
WildFly could stop setting them.
But 3 in particular I thought we should all discuss and decide
on..
1) hibernate.implicit_naming_strategy - by default Hibernate uses its
legacy implicit naming strategy which predates the clarifications made in
JPA 2.0 by many years. The question here is whether we want to change this
(now/ever) to use the JPA (2.0) compliant one?
From a few weeks ago on
https://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg12650.html:
"
Question: Should
hibernate.implicit_naming_strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl
be the default for Hibernate 5?
Answer:
This is one of those things similar to "use new id generator mappings".
For new development I think it probably makes sense for WildFly users to
expect JPA-compliant implicit naming. The difficulty is how changing
that would affect existing applications.
"
Is the ORM default exactly the same as pre-5? If not, is there a jira
that explains the difference?
2) hibernate.auto_quote_keyword - by default we decided to have Hibernate
automatically quote identifiers it thinks are key/reserved words in the
underlying database. We know at the moment this is a bit too aggressive as
it pulls in all of SQL:2003 defined keywords. The question is whether we
disable this by default?
3) hibernate.id.new_generator_mappings - by default we currently still map
to the old identifier generators. I personally also think it is time to
change this default. There are some risks here though.
WildFly has been defaulting hibernate.id.new_generator_mappings=true for
the past four years but I don't think that makes this proposed change
any easier for applications that aren't using WildFly EE (JPA) based
deployments.
Take an example... Legacy JPA users would have gotten
MultipleHiLoPerTableGenerator
when they used table-generation. The new mapping for table-generation
would be to use org.hibernate.id.enhanced.TableGenerator. In theory the
enhanced TableGenerator could be made to mimic the same "hi lo" based
values using the correct optimizer (in *theory* because I have not tried
it). If selecting the proper optimizer works this one might not be a
problem and there is no need for data migration. But if it does not, we
really have no migration path for user to migrate data.
Another "difficulty" is that AUTO is mapped *very* differently. AUTO used
to map to the idea of a "native" generator which would choose between
IDENTITY, SEQUENCE, etc. The new mapping is to use the enhanced
SequenceStyleGenerator. For dialects where the old mapping picked
IDENTITY, this is a very difficult migration point. Granted they could
change all the needed id mappings to specify identity...
And of course we could also just say "this is a (painful) migration point"
and document the known migration issues for existing apps in the migration
guide.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev