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

On Mon, Aug 3, 2015 at 2:07 PM Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: 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. This is such a non-argument. We could of course say the inverse: If WildFly used the same defaults as ORM then (obviously) WildFly could stop setting them. Not to mention Hibernate users would get a more consistent experience across environments.

IMO, the JPA annnotations should generate tables/columns/etc that are JPA-compliant by default. If a developer is adding JPA annotations, I think there is a pretty good likelihood they will be referring to Javadoc or looking at the annnotations interface itself in an IDE. I think there would be an expectation that the generated names due to the JPA annotations would be consistent with what is documented. I think there is also an expectation that the generated names would be portable. Here are some examples of bugs I fixed in 4.2/4.3 where generated names were not consistent with JPA2: - HHH-9387 (generated table name for @ElementCollection uses entity class name; should use entity name); - HHH-9389 (generated join column for @ElementCollection uses entity class name; should use entity name); - HHH-9390 (generated foreign key column name for unidirectional @ManyToMany uses owning entity primary table name; should use owning entity name. I agree that 4.2/4.3 was not the proper time to make those changes the default because it would be a breaking fix that would affect existing applications. IMO, 5 is a good place to make JPA-compliant naming the default. It would still be a breaking change. Existing applications would need to make necessary changes to either the JPA annotations or to the database objects themselves to become JPA-compliant (and portable).

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? I think it will take some time to get the keyword list right for each dialect. I wouldn't be surprised if different versions of a DBMS would have different keywords. This could complicate things as most dialects are used for multiple versions of a DBMS. If 5.0.0 is released with auto-quoting as a default, and a later 5.0.x version excludes keywords, it will be a breaking change for applications that were developed or migrated to an earlier 5.0 version. Also, auto-quoting keywords (only) is not JPA-compliant.

For what it is worth... At the moment I am leaning towards changing the defaults for: 1) "use new id generator mappings" -> true 2) "auto quote keywords" -> false As I mentioned, to me changing any of these defaults warrants a new CR (and obviously documenting in the migration guide). I plan on cutting that CR tomorrow. On Tue, Aug 4, 2015 at 9:29 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > On Tue, Aug 4, 2015 at 1:51 AM Gail Badner <gbadner(a)redhat.com&gt; wrote: > >> >> IMO, the JPA annnotations should generate tables/columns/etc that are >> JPA-compliant by default. If a developer is adding JPA annotations, I think >> there is a pretty good likelihood they will be referring to Javadoc or >> looking at the annnotations interface itself in an IDE. I think there would >> be an expectation that the generated names due to the JPA annotations would >> be consistent with what is documented. I think there is also an expectation >> that the generated names would be portable. >> >> Here are some examples of bugs I fixed in 4.2/4.3 where generated names >> were not consistent with JPA2: >> - HHH-9387 (generated table name for @ElementCollection uses entity >> class name; should use entity name); >> - HHH-9389 (generated join column for @ElementCollection uses entity >> class name; should use entity name); >> - HHH-9390 (generated foreign key column name for unidirectional >> @ManyToMany uses owning entity primary table name; should use owning entity >> name. >> >> I agree that 4.2/4.3 was not the proper time to make those changes the >> default because it would be a breaking fix that would affect existing >> applications. >> >> IMO, 5 is a good place to make JPA-compliant naming the default. It >> would still be a breaking change. Existing applications would need to make >> necessary changes to either the JPA annotations or to the database objects >> themselves to become JPA-compliant (and portable). >> > > What the TCK wants has zero sway on what Hibernate should do *by > default*. Users reading the Javadoc/source is certainly a valid argument. > > And I completely disagree about the "appropriate time" to change > defaults. In fact to me 3.5 would have been the best time to make this > change, which is the version of Hibernate that supported JPA 2.0, when > these implicit names become standardized. > > And also "existing applications would need to make necessary changes to > either the JPA annotations or to the database objects" is just completely > wrong, in the same way it is wrong to assume that "JPA compliant > applications" suddenly need to "make necessary changes to either the JPA > annotations or to the database objects" just to use Hibernate as the > persistence provider. You just stated the entire reason for this being a > pluggable strategy. > > Hibernate does not have to be JPA compliant out of the box. It just > needs to be able to operate in a JPA-compliant way. So to me these > arguments that we should change the default <something> to the more > JPA-compliant one because we should be compliant ar e circular. No. We > should chose defaults we feel make sense. As long as users (and the TCK is > just a user to me in this sense) wanting "strict JPA compliance" can > achieve that, we are good. > > To be honest I *really* don't care strongly one way or the other. But I > do care about reasons/justifications. Change just to change is not good. > I do generally tend to lean towards the existing default in cases where > there is not a compelling reason to change; especially when the change > affects existing application's ability to upgrade. "So that we can be more > spec compliant" is not an argument for me as to why we should change a > setting default. > > Coming back to the idea of annotation javadoc/source.. Again I think > thats a great and valid argument. However, keep in mind that what I don't > want is different defaults/expectations when someone uses annotations or > orm.xml or hbm.xml. There should be a consistent experience for users in > this regard. Also, in developing 5.0 another thing I noticed is that > hbm.xml and annotations/orm.xml bind implicit names differently; that is, > different ImplicitNamingStrategy methods get called for the same logical > concept between them. But that's an inconsistency we need to deal with for > now. > > > > > > 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? >> >> I think it will take some time to get the keyword list right for each >> dialect. I wouldn't be surprised if different versions of a DBMS would have >> different keywords. This could complicate things as most dialects are used >> for multiple versions of a DBMS. >> >> If 5.0.0 is released with auto-quoting as a default, and a later 5.0.x >> version excludes keywords, it will be a breaking change for applications >> that were developed or migrated to an earlier 5.0 version. >> >> Also, auto-quoting keywords (only) is not JPA-compliant. >> > > As I mentioned above, I am tired of hearing this as an argument for > setting defaults :) And here its not even true. Show me where the spec > says that a provider cannot automatically quote SQL identifiers that are > keywords... I'll wait... ;) Because it is simply not there. You are > confusing a problem in the TCK run because of this feature being too > aggressive at the moment with being compliant or not with the spec. > > Again, I am ok changing this default. But I'd like some valid compelling > arguments for it. Actually for this one I think I am convinced to disable > it by default. But more so because of it being overly aggressive at the > moment. Also, in a way it is nice to make users opt-in to such features. > >