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(a)hibernate.org&gt; 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(a)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 >