Spring Boot: JPA Relationships
Spring Boot JPA Relationships
📘 JPA Relationships
Spring Boot provides an implementation of the Java Persistence API
(JPA
) to simplify database access: ORM (Object-Relational Mapping
)
In JPA, entity classes represent tables in the database, and relationships between entities are mapped using annotations.
There are three basic relationships:
- OneToOne: Represents a single-valued association
- OneToMany / ManyToOne: Represents a multi-valued association
- ManyToMany: Represents a multi-valued association where multiple instances
1 JPA Relationships
JPA (Java Persistence API)
provides several types of relationships to model associations between entities :
OneToOne: Represents a single-valued association where an instance of one entity is related to a single instance of another entity.
OneToMany: Represents a multi-valued association where an instance of one entity can be related to multiple instances of another entity.
ManyToOne: The inverse of
OneToMany
, where multiple instances of an entity can be related to a single instance of another entity.ManyToMany: Represents a multi-valued association where multiple instances of one entity can be related to multiple instances of another entity.
These relationships can be either unidirectional
or bidirectional
:
- Unidirectional: Only one entity has a reference to the other.
- Bidirectional: Both entities have references to each other.
Relationships are typically annotated in entity classes using
@OneToOne
,@OneToMany
,@ManyToOne
, or@ManyToMany
. Additional annotations like@JoinColumn
andmappedBy
are used to specify the joining strategy and the owning side of the relationship.
1.1 OneToMany and ManyToOne
OneToMany
Unidirectional
- One entity has a collection of another entity
- Only the owning side (the “One” side) has a reference to the other entity
- Example: One Department has many Employees
@Entity
public class Department {
@OneToMany
private List<Employee> employees;
}
@Entity
public class Employee {
// No reference to Department
}
1.1.1 @OneToMany attributes
Eager loading fetches all required data upfront when an object is first loaded. It immediately initializes and loads related entities or resources, ensuring everything is readily available.
This approach can improve performance for frequently accessed data but may increase initial load times and memory usage.
Lazy loading, conversely, defers data loading until it’s explicitly requested. It retrieves only the essential data initially, loading related entities or resources on-demand when accessed.
This method can enhance initial performance and reduce memory consumption, particularly for large datasets or infrequently used resources.
However, it may introduce slight delays when accessing lazy-loaded data for the first time
- fetch: Specifies whether to lazily or eagerly load the related entities. Default is FetchType.
LAZY
. - cascade: Specifies which operations should cascade to child entities. Options include
ALL
,PERSIST
,MERGE
,REMOVE
, etc. - orphanRemoval: If true, removes child entities when they are removed from the collection. Default is
false
. - mappedBy: Specifies the field that owns the relationship in the child entity.
- optional: If
false
, a non-null relationship must always exist.
Eager loading fetches all related data immediately, making everything available upfront. It can be faster for frequent access but may use more memory.
Lazy loading, on the other hand, loads related data only when requested, initializing it on-demand. This approach saves memory but might cause slight delays on first access.
Key Points
- For @OneToMany and @ManyToMany, the default fetch type is
LAZY
. - For @ManyToOne and @OneToOne, the default fetch type is
EAGER5
. - Using FetchType.
LAZY
is generally recommended to avoid performance issues, especially for collections. - The
cascade
attribute determines which operations should be cascaded from parent to child entities. - The
orphanRemoval
attribute is useful for automatically removing child entities when they are no longer referenced by the parent.
ManyToOne Unidirectional
ManyToOne Unidirectional example: Order and Customer
- Many entities are associated with one entity
- Only the owning side (the “Many” side) has a reference to the other entity
- Example: Many Employees belong to one Department
@Entity
public class Employee {
@ManyToOne
private Department department;
}
@Entity
public class Department {
// No reference to Employee
}
Bidirectional Relationships
Bidirectional Relationships example:
- Both entities have references to each other
- The “Many” side is usually the owning side
- Example: One Department has many Employees, and each Employee belongs to one Department
@Entity
public class Department {
@OneToMany(mappedBy = "department")
private List<Employee> employees;
}
@Entity
public class Employee {
@ManyToOne
private Department department;
}
In bidirectional relationships, use
mappedBy
on the non-owning side to indicate the owning side’s field name.
Serialization is the process of converting an object or class into a byte stream. This byte stream can then be easily saved to a file, sent over a network, or stored in a database.
Hibernate
uses serialization to create deep copies of entity objects for various purposes, such as detached entities, Session Management or caching.
For example: Collections within entities (like an ArrayList<Menu> menus
within a Order
entity ) are often serialized to store them efficiently in the database or to manage state changes.
Implementing Serializable
is not always the best solution. In some cases, it might be better to adjust your entity relationships (@OneToMany
) or use different mapping strategies (@ElementCollection
for simple collections).
1.1.2 Casting
The original code avoids these issues by declaring orderToSave directly as TakeAwayOrder, eliminating the need for casting. This approach is generally preferred when possible, as it’s safer and more straightforward.
// Assume OrderRestaurant is a superclass of TakeAwayOrder
OrderRestaurant orderToSave = new TakeAwayOrder(
"T11", new Date(), "Alice", 1, 10.99,
true, new ArrayList<>(Arrays.asList(menu1)), null );
// We need to cast here
((TakeAwayOrder) orderToSave).setCustomerTakeAway(customer1);
// We might need to cast here too, depending on the repository's type parameter
takeAwayOrderRepository.save((TakeAwayOrder) orderToSave);
- Upcasting: When we assigned a TakeAwayOrder object to an OrderRestaurant variable, we performed an implicit upcast. This is always safe because a TakeAwayOrder is an OrderRestaurant.
- Downcasting: When we cast orderToSave back to TakeAwayOrder, we’re performing a downcast. This is potentially risky because not all OrderRestaurant objects are TakeAwayOrder objects.
- Type safety: Downcasting can lead to runtime errors if the object isn’t actually of the type you’re casting to.
- Code readability: Excessive casting can make code harder to read and understand.
- Performance: While minor, casting does involve a runtime check.
1.2 ManyToMany
ManyToMany Unidirectional
- Multiple entities are associated with multiple entities of another type
- Only one side has a reference to the other entity
- Example: Many Students can enroll in many Courses
@Entity
public class Student {
@ManyToMany
@JoinTable(name = "STUDENT_COURSE",
joinColumns = @JoinColumn(name = "STUDENT_ID"),
inverseJoinColumns = @JoinColumn(name = "COURSE_ID"))
private Set<Course> courses;
}
@Entity
public class Course {
// No reference to Student
}
ManyToMany Bidirectional
- Both entities have references to each other
- One side is designated as the owning side, the other the inverse side
- Example: Many Students can enroll in many Courses, and each Course can have many Students
@Entity
public class Student {
@ManyToMany
@JoinTable(name = "STUDENT_COURSE",
joinColumns = @JoinColumn(name = "STUDENT_ID"),
inverseJoinColumns = @JoinColumn(name = "COURSE_ID"))
private Set<Course> courses;
}
@Entity
public class Course {
@ManyToMany(mappedBy = "COURSES")
private Set<Student> students;
}
In bidirectional ManyToMany relationships, use
mappedBy
on the non-owning side to indicate the owning side’s field name. The@JoinTable
annotation is used to specify the join table details.
ManyToMany
relationships often require a join table in the database- Consider using an intermediate entity for complex relationships or when additional attributes are needed for the relationship
- Be cautious of performance implications with large datasets
1.2.1 OrphanRemoval and Cascade
Cascade
propagates operations from parent to child entities, whileorphanRemoval
automatically deletes child entities no longer associated with a parent.
Cascade
affects specified actions (e.g., PERSIST
, REMOVE
), whereas orphanRemoval
only deals with removing disassociated children.
The main differences between cascade
and orphanRemoval
in JPA are:
Scope of operation:
Cascade
applies to all operations specified (e.g.PERSIST
,MERGE
, RE`MOVE, etc.) and propagates them from parent to child entities<.OrphanRemoval
only deals with removing child entities that are no longer associated with the parent .
When they take effect:
Cascade
operations occur when the specified action is performed on the parent entity .OrphanRemoval
occurs when a child entity is disassociated from its parent, even without explicitly calling remove.
Use cases:
Cascade
is useful for propagating operations like persist or remove from parent to children.OrphanRemoval
is useful for automatically deleting child entities that are no longer referenced by a parent.
Behavior:
CascadeType.REMOVE
will only delete child entities when the parent is explicitly removed.OrphanRemoval
will delete child entities as soon as they are disassociated from the parent, even if the parent is not removed
Combining them:
- They can be used together.
CascadeType.ALL
withorphanRemoval=true
provides the most comprehensive cascading behavior.
- They can be used together.
1.2.1.1 Example: Student
and Course
Entities
Let’s see an example involving Student
and Course
entities in a school system, where orphan removal is meaningful.
Student @Entity
owner-side
import javax.persistence.*;
import java.util.HashSet;
import java.util.Set;
@Entity
public class Student {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String name;
@ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE},
orphanRemoval = true)
@JoinTable(
name = "student_course",
joinColumns = @JoinColumn(name = "STUDENT_ID"),
inverseJoinColumns = @JoinColumn(name = "COURSE_ID")
)
private Set<Course> courses = new HashSet<>();
// Constructors, getters, setters, and utility methods
public void enrollInCourse(Course course) {
courses.add(course);
course.getStudents().add(this);
// Maintain bidirectional relationship
}
public void dropCourse(Course course) {
courses.remove(course);
course.getStudents().remove(this);
// Maintain bidirectional relationship
}
}
Course @Entity
inverse-side
import javax.persistence.*;
import java.util.HashSet;
import java.util.Set;
@Entity
public class Course {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String title;
@ManyToMany(mappedBy = "COURSES")
private Set<Student> students = new HashSet<>();
// Constructors, getters, setters, and utility methods
}
Here’s how we use these entities
in a service or test:
public class SchoolService {
@Autowired
private StudentRepository studentRepository;
@Autowired
private CourseRepository courseRepository;
public void manageEnrollment() {
// Create some courses
Course math = new Course("Mathematics");
Course science = new Course("Science");
// Save courses
courseRepository.save(math);
courseRepository.save(science);
// Create a student and enroll in courses
Student issac = new Student("Isaac Boncodi");
issac.enrollInCourse(math);
issac.enrollInCourse(science);
// Save the student (this will also
// save the relationships)
studentRepository.save(issac);
// Drop the Science course
issac.dropCourse(science);
// Now if we save issac again, the Science course
// will be removed from the database
// if no other students are enrolled in it.
studentRepository.save(issac);
// The Science course will be removed
// if it's no longer associated with any students.
}
}
Entities:
Student
andCourse
are related through a many-to-many relationship with a join table (student_course
).Orphan Removal: The
orphanRemoval = true
attribute in theStudent
class means that if aStudent
drops aCourse
, and no other students are enrolled in that course, it will be removed from the database.Methods:
enrollInCourse
: Adds a course to a student’s list and maintains the bidirectional relationship.dropCourse
: Removes a course from a student’s list and maintains the bidirectional relationship.
Usage: When you drop a course and save the
Student
, if that course is no longer associated with any other students, it will be deleted from the database.
1.2.2 ManyToMany with Join Table @Entity
@Entity @ManyToMany with Join Table: in this particular case we will use two @OneToMany relationships to create a many-to-many, centered and owned by the join table.
- Represents a
many-to-many
relationship using an intermediate entity - The
join table
becomes an entity itself, with twoone-to-many
relationships - Provides more flexibility and allows additional attributes on the relationship
- Example: Students enrolled in Courses, with additional enrollment information
@Entity
public class Student {
@OneToMany(mappedBy = "student")
private List<Enrollment> enrollments;
}
@Entity
public class Course {
@OneToMany(mappedBy = "course")
private List<Enrollment> enrollments;
}
@Entity
public class Enrollment {
@ManyToOne
private Student student;
@ManyToOne
private Course course;
private LocalDate enrollmentDate;
private String grade;
}
In this approach:
- The
Enrollment
entity serves as the join table - It has two
@ManyToOne
relationships: one toStudent
and one toCourse
- Additional fields like
enrollmentDate
andgrade
can be added to theEnrollment
entity - Both
Student
andCourse
have@OneToMany
relationships toEnrollment
- The mappedBy attribute in @OneToMany indicates the owning side of the relationship
This structure allows for more detailed modeling of the relationship between students and courses, enabling the storage of relationship-specific data and easier querying of the association.
Key Points
This structure allows you to:
- Add additional fields to the relationship (e.g., enrollmentDate)
- Easily
query
the relationship from both sides - Maintain better control over the
lifecycle
of the relationship
1.2.3 When two objects are equal? Object Identity
The difference between comparing objects based on object identity and comparing them based on field values lies in how equality is determined:
- by identity, that is, by using their memory addresses
- by their field values
Object Identity
- Object Identity refers to comparing objects using their memory addresses (i.e., whether they are the same instance in memory).
- In Java, this is done using the
==
operator. - Two objects are considered equal based on object identity if they refer to the same memory location.
Field Values
- Field Values refer to comparing objects based on the values of their fields.
- In Java, this is typically done using the
equals
method. - Two objects are considered equal based on field values if their corresponding fields have the same values, even if they are different instances in memory.
Example:
Consider the following MenuRestaurant
class:
public class MenuRestaurant {
private int id;
private String name;
// Constructors, getters, and setters
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
MenuRestaurant that = (MenuRestaurant) o;
return id == that.id && Objects.equals(name, that.name);
}
@Override
public int hashCode() {
return Objects.hash(id, name);
}
}
Comparing Based on Object Identity
MenuRestaurant menu1 =
new MenuRestaurant(1, "Pizza");
MenuRestaurant menu2 =
new MenuRestaurant(1, "Pizza");
System.out.println(menu1 == menu2);
// false, because they are different instances
Comparing Based on Field Values
1.2.4 Using AssertJ with Comparator
usingElementComparator(Comparator.comparing(MenuRestaurant::getId))
When you use the above expression, you are specifying that the comparison should be based on the id
field of the MenuRestaurant
objects:
In this case, the comparison is based on the id
field, not the object identity or the default equals
method. This allows you to verify that the collection contains the expected elements based on their IDs, regardless of their memory addresses.
2 Labs
Here are some of the most common JPA mappings and relationships used in Spring Boot
2.1 @OneToMany
@OneToMany
: This annotation is used to represent a one-to-many relationship between two entities.
For example, if a customer can have multiple orders, you can define a @OneToMany relationship between the Customer entity and the Order entity.
2.2 @ManyToOne
@ManyToOne
: This annotation is used to represent a many-to-one relationship between two entities.
For example, if an order belongs to a customer, you can define a @ManyToOne relationship between the Order entity and the Customer entity.
2.3 @ManyToMany
@ManyToMany
: This annotation is used to represent a many-to-many relationship between two entities.
For example, if a book can have multiple authors and an author can have written multiple books, you can define a @ManyToMany relationship between the Book entity and the Author entity.