[hibernate-dev] 5.0 defaults

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.