Re: [hibernate-dev] 5.0 defaults

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. > >