[hibernate-dev] Naming strategies 4.3 -> 5.0

Wed Aug 19 12:09:44 EDT 2015

Yes, I am talking about the "collection table" name.  That is why I
mentioned @JoinTable.

Again, we correctly produce the  JPA-compliant name, as I said.  The issue
is that we do not seem to produce the correct (what I expected) legacy name.

In trying to verify what that legacy name should be.  Reading through the
delegation and delegators etc did not help me.  And even the doc did not
answer my question.  For the doc, from a user's perspective, I believe we
have 2 questions to answer:

1) How do I achieve JPA compatible implicit naming?
2) How do I achieve backwards-compatible naming (relative to Hibernate's
previous default behavior)?

I will make sure the new documentation covers those topics.

Anyway, I added a test that verifies the multitude of ways users might
specify a naming
strategy: org.hibernate.test.namingstrategy.collectionJoinTableNaming.CollectionJoinTableNamingTest.
I put this on 4.3 and master.

In my opinion I missed how @ManyToMany implicit table naming used to work.
I will correct that for today's Final.  It means a minor change to
the org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyHbmImpl
strategy.

On Mon, Aug 17, 2015 at 4:57 PM Gail Badner <gbadner at redhat.com> wrote:

> See below...
>
> On Sat, Aug 15, 2015 at 7:25 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I think I may have goofed when I implemented some of the
>> ImplicitNamingStrategy rules in 5.0.
>>
>> During that transition, I wrote a bunch of unit test in 4.3 to serve as a
>> baseline to make sure I got the logic/rules right as I developed 5.0.  But
>> I think I may have set up those initial 4.3 tests improperly.
>> Specifically, there are a few meant to test Hibernate's legacy naming
>> behavior, aka its non-JPA-compliant naming.
>>
>> I think I got confused by the whole concept of NamingStrategy and
>> NamingStrategyDelegate and NamingStrategyDelegator that had gotten added
>> to
>> 4.3.
>>
>> So on 4.3, what is the proper way to specify Hibernate should use
>> JPA-compliant implicit naming?  What is the proper way to specify that it
>> should use its legacy naming?
>>
>
> This is well-documented at:
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#configuration-namingstrategy
>
> There are also some properties that are available for use with Entity
> Manager (only documented in
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#configuration-misc-properties
> ):
> - hibernate.ejb.naming_strategy
> -hibernate.ejb.naming_strategy_delegator
>
>
>>
>> The issue came to light via HHH-9908.  Consider a mapping like:
>>
>> @Entity
>> @Table(name = "ptx")
>> public class Ptx {
>>
>>     @Id
>>     private Integer id;
>>
>>     @ManyToMany
>>     private List<Input> inputs1;
>>
>> }
>>
>
>>
>> Assuming that Inputs defines its primary table as "input", the
>> JPA-compliant naming would be "ptx_input".  That is what happens on 4.3
>> using EJB3NamingStrategy.  It is actually also what happens on master
>> using
>> ImplicitNamingStrategyJpaCompliantImpl.
>>
>> However, the "legacy" part I cannot figure out.  Unless I misremember,
>> back
>> in the day we used to interpret these based on the attribute name, rather
>> than the associated table name.  So here we'd have "ptx_inputs1".  That is
>> in fact what ImprovedNamingStrategy does on 4.3.  But I
>> believe ImprovedNamingStrategy is not the default on 4.3.  Again, between
>> NamingStrategy and NamingStrategyDelegate and NamingStrategyDelegator it
>> is
>> VERY hard to understand what it going on, so maybe I just missed
>> something.  Anyway, on 4.3 setting no naming strategy forces this to
>> behave
>> in a JPA-compliant way, meaning the implicit name here is "ptx_input" when
>> I do not specify anything for NamingStrategy(Delegat(e/or)).  So either
>> that got screwed up in 4.2/4.3 (whenever those new indirections where
>> added) or I simply misremember what we used to do here.
>>
>
> Are you talking about the generated table name, or the foreign key name? I
> see that the test case attached to HHH-9908 uses Spring. Do you have a test
> case for this that does not use Spring?
>
> HHH-9390 fixed a bug when generating the default foreign key name in a
> unidirectional many-to-many that refers to the owner.
>
> Ih JSR 388, 2.10.5.2 Unidirectional ManyToMany Relationships:
>
> "Entity A is mapped to a table named A.
> Entity B is mapped to a table named B.
> There is a join table that is named A_B (owner name first). This join
> table has two foreign key columns. One foreign key column refers to table A
> and has the same type as the primary key of table A. The name of this
> foreign key column is formed as the concatenation of the following: the
> name of entity A; " _"; the name of the primary key column in table A. The
> other foreign key column refers to table B and has the same type as the
> primary key of table B. The name of this foreign key column is formed as
> the concatenation of the following: the name of the relationship property
> or field of entity A; " _ "; the name of the primary key column in table B"
>
> The legacy behavior differed for the first FK:
> "The name of this foreign key column is formed as the concatenation of the
> following: the name of entity A; " _"; the name of the primary key column
> in table A."
>
> The legacy behavior was to use the table name (not the entity name).
>
> The JPA-compliant behavior is provided by ImprovedNamingStrategyDelegator#jpaNamingStrategyDelegate,
> which, by default, is of type JpaNamingStrategyDelegate. It will properly
> use the entity name.
>
> This difference is illustrated in
> org.hibernate.test.annotations.manytomany.defaults.DefaultNamingManyToManyTest#testUnidirOwnerEntityNamePrimaryTableOverride
> and extended by ImprovedManyToManyDefaultsTestFor (this was done before you
> mentioned your strong dislike for testing using inheritance...):
>
> As far as I know, collection table naming and the other FK (that
> references the associated entity) were unchanged by my fixes.
>
> Also, the spec wrt the join table name and FKs for bidirectional
> many-to-many is different from unidirectional. I did not find any problems
> with how Hibernate was generating the join table or FKs for bidirectional
> many-to-many.
>
> If there is a specific case that doesn't look right, please create a test
> case that reproduces it and I'll take a look.
>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>