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
