@OneToOne or @ManyToOne
Applies to ✅ Open Source Edition ✅ Express Edition ✅ Professional Edition ✅ Enterprise Edition
In JPA, you may have a @ManyToOne mapping like this:
@Entity
public class Book {
@Id
@GeneratedValue
private Long id;
@Column
private String title;
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "language_id")
private Language language;
// [...]
}
In JPA, you get to specify whether such associations should be fetched eagerly or lazily. In jOOQ, this is irrelevant as you will always express your intent explicitly via a query. Nothing is ever done automatically.
From a mapping perspective, it can be convenient to nest a parent object in the child object (irrespective of whether this is a @OneToOne or @ManyToOne relationship). In jOOQ, such a mapping is always ad-hoc, on a per query basis, so it does not need to reflect your actual database model. For example, you can easily "nest" a Title in a Book. With jOOQ, nesting is done directly in SQL using ORDBMS features (native or emulated).
So, instead of having entity classes, you might have DTOs like these (note, we might not need to project the ID):
public record Language(String code, String description) {}
public record Book(String title, Language language) {}
The DTOs may be reusable or ad-hoc, per query, it's entirely up to you. And you map your query data into the above records as follows:
create.select(
BOOK.TITLE,
// Nested record here:
row(
// Implicit join here
BOOK.language().CD,
BOOK.language().DESCRIPTION
// Ad-hoc converter here:
).mapping(Language::new))
.from(BOOK)
// Ad-hoc converter here
.fetch(Records.mapping(Book::new));
The above mapping is completely compile time type safe.
Some of the jOOQ features used in this section are:
- ad-hoc conversion
- nested records
- implicit joins (these are optional to the task of nesting, but greatly simplify it)
Feedback
Do you have any feedback about this page? We'd love to hear it!