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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
