What is “the inverse side of the association” in a bidirectional JPA OneToMany/ManyToOne association?

java

encapsulation

performance

orm

byAlex Kataev·Nov 16, 2024

In JPA bidirectional relationships, the inverse side has the mappedBy attribute. This entity doesn't manage the connection: instead, a Child entity handles it's association with a Parent. Here's a code snippet that illustrates what we're talking about:

@Entity
public class Parent {
    @OneToMany(mappedBy="parent")
    // These children don't manage their parents. Could make a serious bedtime story.
    private List<Child> children;
}

@Entity
public class Child {
    @ManyToOne
    // This child knows who their parent is and isn't afraid to show it!
    private Parent parent;
}

Parent entities know their Children, but they don't manage the relationship, that's up to the Child entities.

When to take a step back

Designating one side of a relationship as the non-owning (or inverse) side can result in:

Improved encapsulation: Restrict control to one side.
Better performance: Only one side (the owning side) manages changes, avoiding double mapping.
Increased data consistency: Avoiding confusion and potential mismatches caused by having both sides try to control updates.

Here's a tip: It's often better to let the many side of a OneToMany/ManyToOne take charge. It simplifies the join process and reduces foreign key exposure.

What happens when you pick a side

Data management

Assigning ownership to one side and inverse to the other means the ORM can create an efficient and accurate schema, leading to improved query performance.

Pitfall prevention

Without the mappedBy attribute, you may find yourself in tangled relationships (ORM expects two independent mappings), which may result in errors.

Effective architecture

The inverse side doesn't dictate the relationship direction using join columns or tables: it leaves this to the mappedBy property. A smart decision, you might say, simplifying your entity design significantly.

Deep dive into robust applications

Design Patterns

Many-to-one as owner is a reliable and common design pattern. Stick to it when possible for streamlined ORM, mirroring database schemas naturally.

Beware of Potential Pitfalls

Consider the implications before using an additional table for relationships. It’s flexible, but it adds complexity, may affect performance, and is ripe for errors.

Applying it all

In complex domains or intricate business scenarios, an additional table might become a necessity. Just remember, heavy is the head that wears the mappedBy crown.

explain-codes / Java / What is “the inverse side of the association” in a bidirectional JPA OneToMany/ManyToOne association?

Linked

What is the "owning side" in an ORM mapping?



Can someone explain mappedBy in JPA and Hibernate?



What is the meaning of the CascadeType.ALL for a @ManyToOne JPA association



Integrity constraint violation: 1452 Cannot add or update a child row:



Default fetch type for one-to-one, many-to-one and one-to-many in Hibernate

