Bidirectional many to many mapping

[Linwood Hayes]

It is said that "mappedBy" is reuired for bi-directional many-to-many mapping.   I am wondering what if I don't have "mappedBy".  For example


TABLE:  EMPLOYEE

ID FIRSTNAME LASTNAME
1 Bob Way
2 Sarah Smith

-----------------------------------------------------

TABLE:  EMP_PROJ (many to many link table)

EMP_ID PROJ_ID
1          1
1          2
2          1
-----------------------------------------------------

TABLE:  PROJECT

ID NAME
1 GIS
2 SIG
-------------------------------------------------------

@Entity
public class Employee {
  @Id
  @Column(name="ID")
  private long id;
  ...
  @ManyToMany
  @JoinTable(
      name="EMP_PROJ",
      joinColumns=@JoinColumn(name="EMP_ID", referencedColumnName="ID"),
      inverseJoinColumns=@JoinColumn(name="PROJ_ID", referencedColumnName="ID"))
  private List<Project> projects;
  .....
}

@Entity
public class Project {
  @Id
  @Column(name="ID")
  private long id;
  ...
  @ManyToMany
  @JoinTable(
      name="EMP_PROJ",
      joinColumns=@JoinColumn(name="PROJ_ID", referencedColumnName="ID"),
      inverseJoinColumns=@JoinColumn(name="EMP_ID", referencedColumnName="ID"))
  private List<Employee> employees;
  .....
}

Isn't this a many-to-many bidirectional mapping ? And it does not use "mappedBy".  Please share your thought.

[Frits Walraven]

When you don't have a mappedBy attribute JPA will create two unidirectional many-to-many relationships, having two different join tables. You can see that if you remove the @JoinTable annotations from your example and let JPA create the default mapping.

[Roel De Nijs]

Linwood Hayes wrote:Isn't this a many-to-many bidirectional mapping ? And it does not use "mappedBy".  Please share your thought.

No, it isn't. If you look at the javadoc of the mappedBy attribute of the @ManyToMany annotation, you'll notice that this attribute is required if you want a bidirectional relationship.

[Linwood Hayes]

Roel De Nijs wrote:

Linwood Hayes wrote:Isn't this a many-to-many bidirectional mapping ? And it does not use "mappedBy".  Please share your thought.

No, it isn't. If you look at the javadoc of the mappedBy attribute of the @ManyToMany annotation, you'll notice that this attribute is required if you want a bidirectional relationship.

So, what will happen if I use the code I have ??  I only have one link table (I created table prior to anything).  Could you be more specific ?

[Linwood Hayes]

Frits Walraven wrote:When you don't have a mappedBy attribute JPA will create two unidirectional many-to-many relationships, having two different join tables. You can see that if you remove the @JoinTable annotations from your example and let JPA create the default mapping.

I don't get it.  Table design was done prior to any java code and it was designed to have only one link table.  what do you mean it will create two different join tables ?

[Frits Walraven]

I don't get it.  Table design was done prior to any java code and it was designed to have only one link table.  what do you mean it will create two different join tables ?

Then the mapping to that existing table is not conform how a bidrectional many-to-many relationship should be mapped according to the JPA specifications.

The specification clearly states that the mappedBy attribute is needed for a bi-directional relationship.

2.9 Entity Relationships
The following rules apply to bidirectional relationships:
- The inverse side of a bidirectional relationship must refer to its owning side by use of the mappedBy element of the OneToOne, OneToMany, or ManyToMany annotation. The mappedBy element designates the property or field in the entity that is the owner of the relationship.
... left out the other rules

I was just telling you that you don't see your mistake because you point from both unidirectional many-to-many sides to the same join table. Leaving out the mappedBy attribute by a many-to-many relationship creates an unidirectional relationship with a join-table by default (and in this case two).

[Linwood Hayes]

Frits Walraven wrote:

I don't get it.  Table design was done prior to any java code and it was designed to have only one link table.  what do you mean it will create two different join tables ?

Then the mapping to that existing table is not conform how a bidrectional many-to-many relationship should be mapped according to the JPA specifications.

The specification clearly states that the mappedBy attribute is needed for a bi-directional relationship.

2.9 Entity Relationships
The following rules apply to bidirectional relationships:
- The inverse side of a bidirectional relationship must refer to its owning side by use of the mappedBy element of the OneToOne, OneToMany, or ManyToMany annotation. The mappedBy element designates the property or field in the entity that is the owner of the relationship.
... left out the other rules

I was just telling you that you don't see your mistake because you point from both unidirectional many-to-many sides to the same join table. Leaving out the mappedBy attribute by a many-to-many relationship creates an unidirectional relationship with a join-table by default (and in this case two).

Thanks.  I think I understand what you said.  But can you tell me what would exactly happen if I use my implementation ?

[Roel De Nijs]

Linwood Hayes wrote:But can you tell me what would exactly happen if I use my implementation ?

Would it not be much easier if you have a go and try it yourself? You have the actual code and you probably can easily create a test to persist a few entities and see what happens when you don't use the mappedBy attribute. I have never tried it myself, so I honestly have no clue!

[Frits Walraven]

Linwood Hayes wrote: But can you tell me what would exactly happen if I use my implementation ?

Nobody can tell you as you don't follow the specifications: it might work, it might not. Note that the owning side of a relationship is quite often mentioned in the JPA specification. I won't be surprised that when you merge detached entities you will run into strange (undefined) behaviour.

However, even if it works with one persistence provider, it might fail on another. Bottom line: follow the specifications and you will be sure that your code is correct and portable.