Why the concept of belonging is necessary:
The idea that the bidirectional relation belongs to the party arises because there are no bidirectional relations in relational databases, for example, in the case of objects. In databases, we have only one-way relationships - foreign keys.
What is the reason for the name "owning party"?
The private side of a relationship monitored by Hibernate is the side of the relationship that owns the foreign key in the database.
What is the problem that the idea of owning a party solves?
Take an example of two objects displayed without declaring their own side:
@Entity @Table(name="PERSONS") public class Person { @OneToMany private List<IdDocument> idDocuments; } @Entity @Table(name="ID_DOCUMENTS") public class IdDocument { @ManyToOne private Person person; }
From the point of view of OO, this comparison defines not one bi-directional relationship, but two separate unidirectional relationships.
The mapping would not only PERSONS and ID_DOCUMENTS , but also create the third PERSONS_ID_DOCUMENTS link PERSONS_ID_DOCUMENTS :
CREATE TABLE PERSONS_ID_DOCUMENTS ( persons_id bigint NOT NULL, id_documents_id bigint NOT NULL, CONSTRAINT fk_persons FOREIGN KEY (persons_id) REFERENCES persons (id), CONSTRAINT fk_docs FOREIGN KEY (id_documents_id) REFERENCES id_documents (id), CONSTRAINT pk UNIQUE (id_documents_id) )
Pay attention to the primary key pk only on ID_DOCUMENTS . In this case, Hibernate tracks both sides of the relationship independently: if you add a document to the Person.idDocuments relationship, it inserts an entry into the PERSON_ID_DOCUMENTS association PERSON_ID_DOCUMENTS .
On the other hand, if we call idDocument.setPerson(person) , we change the foreign key person_id to the table ID_DOCUMENTS . Hibernate creates two unidirectional (foreign keys) relationships in the database to implement one bi-directional relationship of the object.
How the concept of the decisive side solves the problem:
In many cases, we want to use only the foreign key in the ID_DOCUMENTS table in relation to PERSONS and an additional association table.
To solve this problem, we need to configure Hibernate to stop tracking changes in relation to Person.idDocuments . Hibernate should only track the other side of the IdDocument.person relationship, and for this we add mappedBy :
@OneToMany(mappedBy="person") private List<IdDocument> idDocuments;
What does this mean: mappedBy?
This means something like: "modifications on this side of the relationship are already displayed using the IdDocument.person relationship on the other side, so there is no need to track it here separately in the additional table.
Are there any gotcha effects?
Using mappedBy . If we call only person.getDocuments().add(document) , the foreign key in ID_DOCUMENTS will be bound to NOT to the new document, because this is not the ownership / tracked side of the relationship!
To associate a document with a new person, you need to explicitly call document.setPerson(person) , because this is the owner side .
When using mappedBy, the developer needs to know what the owner is and update the right side of the relationship in order to make the new relationship persist in the database.