[hibernate-dev] 5.0 defaults

[Scott Marlow]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>