[hibernate-dev] 5.0 defaults

[Steve Ebersole]

On Tue, Aug 4, 2015 at 1:51 AM Gail Badner <gbadner at 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.