Question Details

No question body available.

Tags

spring spring-boot kotlin jooq

Answers (1)

March 31, 2026 Score: 0 Rep: 223,977 Quality: Medium Completeness: 80%

Answering your questions

In a heavily joined, read-heavy web application like this, how do you recommend separating and structuring DTOs for better use of Jooq queries?

The problems you're encountering should lead to conluding that you're projecting way too many columns for all of these queries. jOOQ recommends you never SELECT (where the usage of or jOOQ Table.fields() is considered the same thing). You likely don't need most of these columns and once you start deliberately mapping things, you'll notice that manual mapping isn't such a big chore anymore.

What is the best practice for mapping a Record to a Kotlin data class safely (avoiding name clashes) without drowning in manual mapping boilerplate?

There isn't a "best practice," only tradeoffs. The safest approach, however, is to use constructor references. If you want to ensure you don't accidentally mix up column ordering, you could attach types to all of your columns either manually or using auto-embeddables, for example, or group commonly projected columns using nested records or embeddables

Since I am on jOOQ 3.20, should I be leaning heavily into ROW and MULTISET for structural mapping right at the SQL level, or do you prefer keeping the SQL flat and handling the mapping via Kotlin extension functions/external mappers?

Why wouldn't you? These tools are just tools. They're powerful and very clear in terms of semantics. While you could handle mapping of flat results to some extent, it's not always possible to deduplicate cartesian products (think of multiple child tables joined to a parent table), so you don't really have a choice here, unless you want tons of mapping boilerplate or N+1 queries, etc.

Note, there's a blog post illustrating most commonly used alternatives of nesting algorithms. Again, there's no "best" approach, just tradeoffs, and various tools. Use the right tool when it fits best.

Thinking outside the box

Since you're implementing a web application, I'm assuming your DTOs are then mapped to JSON documents for consumption in a browser. In that case, why not skip all of this stuff and work with SQL/JSON directly? jOOQ supports that as well.