Relationships in JPA: Creating Entities Without Dependency

Relationships in JPA: Creating Entities Without Dependency

When creating a backend API, it's common to work with entity relationships to organize data. Typically, in courses or tutorials, we mostly see bidirectional relationships. But what if you want one entity to exist independently of the other? In this article, we’ll explore how to use a unidirectional relationship with JPA/Hibernate to achieve this.

Table of contents

• Context and Problem
• Entity Modeling
• Scenarios for Saving Data
  • Creating a Student without a ThesisSchedule
  • Updating the Student to Associate with a ThesisSchedule
• Advantages of Managing the Relationship on Student's Side
• Alternative: Managing the Relationship on the ThesisSchedule Side
• Choosing the Right Configuration for Your Needs

Context and Problem:

Imagine you have two entities: Student and ThesisSchedule. The relationship between Student and ThesisSchedule is "many-to-one," meaning that a student can be associated with a thesis schedule, and each schedule can include multiple students.

In this case, our goal is to allow the creation of a Student without requiring a ThesisSchedule to be defined first. This independence is helpful, for instance, when adding students to the database before creating thesis schedules.

• Problem encountered: With a bidirectional or poorly configured relationship, creating a Student may fail if a ThesisSchedule hasn’t been created yet, even with the annotation nullable = true. Let’s see how to solve this with a unidirectional relationship.

Entity Modeling

We’ll create Student and ThesisSchedule classes using a unidirectional "many-to-one" relationship from Student to ThesisSchedule.

Student entity code:

ThesisShedule entity code:

Here, we have a unidirectional relationship from Student to ThesisSchedule, indicated by the @ManyToOne annotation in the Student class. By specifying nullable = true, we allow a Student to be created without necessarily being associated with a ThesisSchedule.

Scenarios for Saving Data

Let’s see how this setup translates to the database and how data can be saved through an API.

Creating a Student without a ThesisSchedule

With this setup, we can create a student without providing a ThesisSchedule.

POST request to create a Student (without ThesisSchedule):

This creates a new entry in the Student table with a null value for the thesis_schedule_id column.

Result:

Updating the Student to Associate with a ThesisSchedule

Once a ThesisSchedule is created, we can update the Student record to associate with it.

Creating a ThesisSchedule:

This newly created ThesisSchedule might have an ID of 1.

Updating the student with ThesisSchedule:

Result:

Now, Larose is associated with the newly created ThesisSchedule.

Advantages of Managing the Relationship on Student's side:

• Creation Flexibility: We can create a Student independently of a ThesisSchedule, allowing for independent entity creation.
• Simplicity of Structure: A unidirectional relationship simplifies interactions, as ThesisSchedule doesn’t need to be aware of the relationship with Student.
• Scalability: If we later need to make this relationship bidirectional, we can update the ThesisSchedule class to include a collection of Student.

Alternative: Managing the Relationship on the ThesisSchedule Side

In some cases, it may be more appropriate to manage the relationship from the ThesisSchedule side. This approach is useful if we want the thesis schedule to manage its associated students, keeping track of those participating in a specific schedule.

Entity Modeling

In this setup, ThesisSchedule holds a collection of Student to represent a "one-to-many" relationship, while Student doesn’t maintain a reference to ThesisSchedule.

ThesisSchedule entity code:

Student entity code:

In this configuration, ThesisSchedule contains a list of Student through the @OneToMany annotation. Consequently, students can be added or removed from ThesisSchedule without requiring a direct link in Student.

Advantages of Managing the Relationship on ThesisSchedule’s Side:

• Data Centralization: All information about students associated with a thesis schedule is centralized in ThesisSchedule, making it easier to access relevant data.
• Increased Control: ThesisSchedule can manage its students, simplifying the handling of groups of students participating in the same schedule.

Choosing the Right Configuration for Your Needs:

In conclusion, whether to manage the relationship on the Student or ThesisSchedule side depends on your application's specific needs:

• Relationship Managed by Student: Use this setup if you want to create students independently of a thesis schedule and optionally link a schedule to a student later.
• Relationship Managed by ThesisSchedule: This option is preferable if the thesis schedule should manage its students, making it the core of the relationship between entities.

Both configurations provide flexibility and allow for well-organized backend APIs based on the desired data relationships. By applying best practices to structure entity relationships, you can effectively model your database to meet your application’s specific needs.

Unidirectional relationships are a powerful option for managing optional dependencies between entities in a backend API.

I hope this solution helps other developers better understand and use unidirectional relationships in JPA/Hibernate.

Comments

[Lewis Florez R.]

My question here is, How many students could have the ThesisSchedule?, more than one, Just one, according to the answer is the design.

[IKITAMA CODES]

For my case the ThesisSchedule had to have more than one Students and it was from there that i discovered this notion.
And as I said in the article, the design depends on the requierements of your database design.