[hibernate-dev] Sharing an association table between two associations

[Steve Ebersole]

The difficulty is recognizing this as an exception condition, which I'd
really prefer to do.  But I just don't see a way to accomplish that without
tables keeping a "nature" indicating how they are used.

On Thu, Mar 19, 2015 at 3:35 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Oops, Adding the mailing list.
> Thanks for the input, we went for two explicit table names in the OGM
> test. Looks like we are aligned.
>
> Emmanuel
>
>
> On 18 mars 2015, at 18:59, Steve Ebersole <steve at hibernate.org> wrote:
>
> Well considering I am the only recipient... ;)
>
> I have actually seen this scenario in one of your annotation test cases.
> Currently, the outcome is actually highly dependent upon the naming
> strategy used.  In my opinion, this should be an invalid mapping.  The spec
> may or may not back me up there, but to me it just "feels" wrong.
>
>
>
> On Wed, Mar 18, 2015 at 10:27 AM, Emmanuel Bernard <emmanuel at hibernate.org
> > wrote:
>
>> Hi Steve and all,
>>
>> There is a borderline case that Hibenate OGM trips on. I would like to
>> know whether you consider this case valid enough or if we can safely
>> ignore it.
>>
>> @Entity
>> public class SnowFlake {
>>     @Id
>>     private String id;
>>     private String description;
>> }
>>
>> @Entity
>> public class Cloud {
>>     @Id
>>     private String id;
>>     private String type;
>>     private double length;
>>     @OneToMany
>>     @JoinTable
>>     private Set<SnowFlake> producedSnowFlakes = new HashSet<SnowFlake>();
>>     @OneToMany
>>     @JoinTable
>>     private Set<SnowFlake> backupSnowFlakes = new HashSet<SnowFlake>();
>> }
>>
>> Here, producedSnowFlakes and backupSnowFlakes have the set semantic, so a
>> PK is
>> created for the association tables.  Except that we use the same
>> association
>> table name Cloud_SnowFlake) for both. The PK offered in Hibernate ORM
>> metadata
>> ends up being wrong.
>> The runtime code works as the target fk columns are named differently.
>>
>> I have always considered it wrong to share the same table for two
>> associations.
>> Are you with me, or should we try to amke the ORM physical model smarter
>> to
>> relax the PK generation when an association table is shared?
>>
>> Emmanuel
>>
>
>