[hibernate-dev] 5.0 defaults

Wed Aug 5 09:43:33 EDT 2015

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