This article is part of the JPA Pitfalls series, and our first topic of discussion is some common JPA relationship mapping pitfalls. JPA makes it really easy to do things the wrong way, and makes it really unintuitive to do things right. In this blog post series, I will go over some common JPA pitfalls and show how to avoid them.
One-to-many relationship mapping
Assuming we have the following database schema:
We could create the following JPA entities:
- Post:
@Entity
class Post {
@Id
@GeneratedValue
private Long id;
private String content;
… // no-args constructor, getters and setters omitted for brevity
}
- Comment:
@Entity
class Comment {
@Id
@GeneratedValue
private Long id;
private String content;
@ManyToOne
private Post post;
… // no-args constructor, getters and setters omitted for brevity
}
Comment entity has a reference to a Post via a @ManyToOne binding.
Now, it might be tempting to also create a bidirectional binding, so that we could have a list of comments when we fetch a post:
@Entity
class Post {
…
@OneToMany(
mappedBy = "post",
cascade = CascadeType.ALL,
orphanRemoval = true
)
private Set<Comment> comments = Set.of();
}
If we fetch a post, we will also get all of the comments as well -- that sounds very convenient. But the problem is that we will get all the comments, and there is no way to make it pageable. Imagine if we had thousands or millions of comments on a post. We would have to fetch them all from our database!
Instead, we could just have a unidirectional @ManyToOne association on the Comment entity, and then we could run a custom query to get all post comments:
@Repository
public interface CommentRepository extends JpaRepository<Comment, Long> {
Set<Comment> findByPost_id(Long postId);
}
We could then make this query pageable simply by passing a Pageable instance into our repository method:
Page<Comment> findByPost_id(Long postId, Pageable pageable);
Many-to-many relationship mapping
Assuming we have the following database schema:
We could map it to the following JPA entities:
- User:
@Entity
class User {
@Id
@GeneratedValue
private Long id;
private String name;
… // no-args constructor, getters and setters omitted for brevity
}
- Movie:
@Entity
class Movie {
@Id
@GeneratedValue
private Long id;
private String title;
… // no-args constructor, getters and setters omitted for brevity
}
We could then use @ManyToMany annotation to connect these two together:
- User:
@Entity
class User {
…
@ManyToMany(cascade = {
CascadeType.PERSIST,
CascadeType.MERGE
})
@JoinTable(
name = "review",
joinColumns = @JoinColumn(name = "user_id"),
inverseJoinColumns = @JoinColumn(name = "movie_id")
)
private Set<Movie> movieReviews;
}
- Movie:
@Entity
class Movie {
…
@ManyToMany(mappedBy = "movieReviews")
private Set<User> userReviews;
}
Unfortunately, we now have the exact same problem that we had with @OneToMany annotation. If we fetch a user, we will get all their movie reviews and vice versa. There is no way to make these queries pageable.
What we could do instead is create a new entity class that represents the join table:
class Review {
@EmbeddedId
private Id id;
@ManyToOne
@MapsId("userId")
private User user;
@ManyToOne
@MapsId("movieId")
private Movie movie;
… // no-args constructor, getters and setters omitted for brevity
@Embeddable
static class Id implements Serializable {
private Long userId;
private Long movieId;
… // no-args constructor, getters, setters, equals, and hashCode omitted for brevity
}
}
We could then run custom queries to fetch what we need:
@Repository
public interface ReviewRepository extends JpaRepository<Review, Long> {
Set<Review> findByUser_id(Long userId);
Set<Review> findByMovie_id(Long movieId);
}
And of course, we could pass in a Pageable instance to get a pageable response:
Page<Review> findByUser_id(Long userId, Pageable pageable);
Page<Review> findByMovie_id(Long movieId, Pageable pageable);
Conclusion
Since it is not possible to create pageable queries using @OneToMany and @ManyToMany annotations, they should usually be avoided. The only exception to this rule is if you know that there will only exist very few associated entities. For example, if we have a User entity and users can have one or more roles assigned to them, then it may be okay to use @OneToMany annotation since we know there aren’t going to be that many user roles.
It would've been better if @OneToMany and @ManyToMany were named @OneToFew and @FewToFew instead to indicate better that they should only be used when there are only a few associated entities. Alternatively, these annotations could just be deprecated or completely removed. The added convenience of these annotations is really minor compared to all the troubles they cause so we would be better without them. Unfortunately, none of this will happen as it is too late now. We can only try and educate people to stop using these annotations everywhere without thinking about performance implications.
This article is part of the JPA Pitfalls series:
- JPA Pitfalls: Eager/Lazy Fetching
- JPA Pitfalls: Generating IDs
About the author
Bojan Stipic is a Software Engineer with over three years of experience working at our engineering hub in Novi Sad.
Bojan is interested in Full-stack web development, systems programming,
programming language design, and compiler development. As for specific technologies, he feels most comfortable using technologies such as Java and React.
