Ok, I am changing my mind ImplicitNamingStratregy as well. Gail's "annotation javadoc" argument swayed me. I have already changed the defaults for keyword-auto-quoting (to false) and use-new-generator-mappings (to true). I will add a change for the default ImplicitNamingStratregy as well for CR4. Additionally I will add some "short naming" for the Hibernate-provided ImplicitNamingStratregy impls.
I will leave strict-jpql-compliance as defaulting to false (support full HQL syntax by default). On Tue, Aug 4, 2015 at 10:29 AM Steve Ebersole <st...@hibernate.org> wrote: > 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 <st...@hibernate.org> wrote: > >> On Tue, Aug 4, 2015 at 1:51 AM Gail Badner <gbad...@redhat.com> 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. >> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
