Implicit join type
Supported by ✅ Open Source Edition ✅ Express Edition ✅ Professional Edition ✅ Enterprise Edition
jOOQ's very useful implicit JOIN feature can be used to use a path notation to join tables on their actual, or synthetic foreign keys. For example:
// Get all books, their authors, and their respective language
create.select(
BOOK.author().FIRST_NAME,
BOOK.author().LAST_NAME,
BOOK.TITLE,
BOOK.language().CD.as("language"))
.from(BOOK)
.fetch();
By default, this produces:
- An
INNER_JOINif all columns of the foreign key areNOT NULL - A
LEFT_JOINif the foreign key is nullable / optional - A
SCALAR_SUBQUERYif the implicit join path is in a DML statement - An exception if the path follows a
to-manyrelationship
The above defaults are important to prevent implicit joins from filtering results when placed in clauses that are not meant to filter, such as the SELECT clause or the ORDER BY clause, as well as to prevent them from generating rows in such cases (in the case of to-many joins).
Users may prefer to enforce a different behaviour, including:
- Always produce a
LEFT_JOIN, e.g. because this was the behaviour before jOOQ 3.14 - Always produce an
INNER_JOIN, e.g. because they're migrating off Hibernate / JPA, and depend on Hibernate's implicit joins producing inner joins - Always produce a
SCALAR_SUBQUERY, to keep scoping of a path local (producing duplicates for shared path segments). This is also what's being done when an implicit join path is rendered in a DML statement. - Always
THROWan exception.
This change of behaviour can be achieved with the following setting:
Example configuration
Settings settings = new Settings()
.withRenderImplicitJoinType(RenderImplicitJoinType.INNER_JOIN)
.withRenderImplicitJoinToManyType(RenderImplicitJoinType.LEFT_JOIN);
Feedback
Do you have any feedback about this page? We'd love to hear it!