[hibernate-dev] 5.0 defaults

[Steve Ebersole]

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 at hibernate.org> wrote:

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