[hibernate-dev] 5.0 defaults

[Steve Ebersole]

Scott has been asking about making some setting defaults consistent between
Hibernate and WildFly.  Most I think WildFly should just use the ORM
defaults.  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?

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.

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.