# jooq-development Published articles for jooq-development. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Resisting the Urge to Document Everything Everywhere DevFeed: [Resisting the Urge to Document Everything Everywhere]() Original publisher: [Read original article]() Author: lukaseder Published: 2025-02-28T10:39:07Z Content type: opinion Language: en Sources: [jOOQ]() Topics: [jooq](), [SQL](), [generics]() Tags: [caveat](), [documentation](), [generics](), [jooq](), [jooq-development](), [quirk](), [sql](), [stack-overflow](), [xyproblem]() ### AI overview The article argues that product teams should resist documenting every workaround alongside the feature that exposed a user's problem. Using jOOQ as an example, it explains that unrelated features can be difficult to discover even when one helps address a quirk or limitation in another. ### Source excerpt Every product manager knows this situation: This is such a common pattern, and while it's perfectly understandable for such a user to request this, it is so terribly wrong to give in to this user's request. Why is it wrong? The features are unrelated Most of the time, the two features X1 and X2 are ... Continue reading Resisting the Urge to Document Everything Everywhere -> ## jOOQ 3.20 released with ClickHouse, Databricks, and much more DuckDB support, new modules, Oracle type hierarchies, more spatial support, decfloat and synonym support, hidden columns, Scala 3, Kotlin 2, and much more DevFeed: [jOOQ 3.20 released with ClickHouse, Databricks, and much more DuckDB support, new modules, Oracle type hierarchies, more spatial support, decfloat and synonym support, hidden columns, Scala 3, Kotlin 2, and much more]() Original publisher: [Read original article]() Author: lukaseder Published: 2025-02-20T10:27:54Z Content type: release Language: en Sources: [jOOQ]() Topics: [clickhouse](), [databricks](), [SQL](), [DuckDB](), [modules](), [Oracle Database](), [Kotlin](), [Scala](), [reactive](), [jpa]() Tags: [array](), [clickhouse](), [databricks](), [decfloat](), [dirty-tracking](), [dml-join](), [duckdb](), [hidden-columns](), [jdk-21](), [jooq](), [jooq-3-20](), [jooq-development](), [jpa](), [json](), [kotlin](), [kotlin-2](), [merge](), [modules](), [oracle](), [oracle-plsql-types](), [r2dbc](), [reactive](), [scala](), [scala-3](), [sequences](), [spatial](), [sql]() ### AI overview jOOQ 3.20 introduces experimental ClickHouse and Databricks SQL dialects, improves DuckDB support, adds new integration modules, and expands support for Oracle type hierarchies, spatial features, decfloat, synonyms, hidden columns, Scala 3, and Kotlin 2. ### Source excerpt New dialects: jOOQ 3.20 ships with 2 new experimental dialects: ClickHouse is a fast-moving SQL dialect with a historic vendor-specific syntax that is gradually migrated to a more standards compliant alternative, which is why our support is still experimental. A lot of behaviours differ from what one would expect elsewhere, including NULL handling, which is ... Continue reading jOOQ 3.20 released with ClickHouse, Databricks, and much more DuckDB support, new modules, Oracle type hierarchies, more spatial support, decfloat and synonym support, hidden columns, Scala 3, Kotlin 2, and much more -> ## jOOQ 3.19's new Explicit and Implicit to-many path joins DevFeed: [jOOQ 3.19's new Explicit and Implicit to-many path joins]() Original publisher: [Read original article]() Author: lukaseder Published: 2023-12-28T14:35:14Z Content type: release Language: en Sources: [jOOQ]() Topics: [jooq](), [jpa](), [SQL]() Tags: [correlated-subqueries](), [explicit-path-joins](), [implicit-join](), [implicit-join-path-correlation](), [implicit-joins](), [java](), [jooq](), [jooq-3-19](), [jooq-development](), [path-joins](), [sql](), [to-many-path-joins]() ### AI overview This article describes jOOQ 3.19's support for explicit path joins and new to-many path joins. It explains how path-based joins can simplify SQL queries, derive join predicates from foreign-key metadata, and allow per-query control over join types. ### Source excerpt jOOQ 3.19 finally delivers on a set of features that will greatly simplify your queries further, after jOOQ 3.11 introduced implicit to-one joins: What are these features? Many ORMs (e.g. JPA, Doctrine, jOOQ 3.11 and others) support "path joins" (they may have different names for this concept). A path join is a join derived from ... Continue reading jOOQ 3.19's new Explicit and Implicit to-many path joins -> ## jOOQ 3.19.0 Released with DuckDB, Trino, Oracle 23c support, join path improvements, an official gradle plugin, commercial maven repositories, policies, UDT paths, trigger meta data, hierarchies, and much more DevFeed: [jOOQ 3.19.0 Released with DuckDB, Trino, Oracle 23c support, join path improvements, an official gradle plugin, commercial maven repositories, policies, UDT paths, trigger meta data, hierarchies, and much more]() Original publisher: [Read original article]() Author: lukaseder Published: 2023-12-15T16:30:41Z Content type: release Language: en Sources: [jOOQ]() Topics: [releases](), [DuckDB](), [CockroachDB](), [Maven](), [Gradle](), [rdbms](), [Multi-tenancy]() Tags: [cockroachdb](), [cockroachdb-23](), [duckdb](), [gradle](), [gradle-plugin](), [implicit-joins](), [java-8](), [join-paths](), [jooq](), [jooq-3-19](), [jooq-development](), [maven](), [maven-repository](), [multi-tenancy](), [oracle-23c](), [policies](), [release-notes](), [releases](), [row-level-security](), [security](), [trigger-meta-data](), [triggers](), [trino](), [trinodb](), [udt-paths](), [udts]() ### AI overview The jOOQ 3.19.0 release adds experimental DuckDB support, Trino support, and support for CockroachDB 23 and Oracle 23c. It also improves join paths, introduces an official Gradle plugin and a commercial Maven repository, and adds policies for row-level security. ### Source excerpt New Dialects It's been a few releases since we've added support for new dialects, but finally some very interesting RDBMS of increasing popularity have joined the jOOQ family including: These dialects are available in all jOOQ editions. New dialect versions In addition to these entirely new dialects, big new CockroachDB and Oracle versions have shipped: ... Continue reading jOOQ 3.19.0 Released with DuckDB, Trino, Oracle 23c support, join path improvements, an official gradle plugin, commercial maven repositories, policies, UDT paths, trigger meta data, hierarchies, and much more -> ## How to Turn a List of Flat Elements into a Hierarchy in Java, SQL, or jOOQ DevFeed: [How to Turn a List of Flat Elements into a Hierarchy in Java, SQL, or jOOQ]() Original publisher: [Read original article]() Author: lukaseder Published: 2023-03-24T15:45:28Z Content type: tutorial Language: en Sources: [jOOQ]() Topics: [Java](), [SQL](), [Jackson](), [JSON](), [Library]() Tags: [code](), [collections](), [collector](), [collectors](), [hierarchical-sql](), [how-to](), [jackson](), [java](), [jooq-development](), [json](), [nested-collections](), [postgresql](), [recursive-sql](), [sql]() ### AI overview A tutorial on converting flat parent-child data into hierarchical structures using SQL, Java, or jOOQ. It compares a recursive PostgreSQL query with jOOQ 3.19 and a reusable pure-Java Collector, and discusses JSON serialization with Jackson and type inference considerations. ### Source excerpt Occasionally, you want to write a SQL query and fetch a hierarchy of data, whose flat representation may look like this: The result might be: |id |parent_id|label | |---|---------|-------------------| |1 | |C: | |2 |1 |eclipse | |3 |2 |configuration | |4 |2 |dropins | |5 |2 |features | |7 |2 |plugins | |8 |2 ... Continue reading How to Turn a List of Flat Elements into a Hierarchy in Java, SQL, or jOOQ -> ## jOOQ 3.17 Supports Implicit Join also in DML DevFeed: [jOOQ 3.17 Supports Implicit Join also in DML]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-08-25T08:07:00Z Content type: article Language: en Sources: [jOOQ]() Topics: [SQL](), [Databases]() Tags: [correlated-subqueries](), [delete](), [dml-join](), [implicit-join](), [join](), [jooq](), [jooq-3-17](), [jooq-development](), [mariadb](), [mysql](), [oracle](), [postgresql](), [sql](), [update]() ### AI overview The article explains that jOOQ 3.17 adds support for implicit join path expressions in DML statements. It describes correlated-subquery emulation, DML JOIN support for selected RDBMS, and planned translation using updatable views in Oracle. ### Source excerpt Since jOOQ 3.11, implicit joins have been supported. An implicit join is a JOIN (mostly a LEFT JOIN) that is generated implicitly because of the presence of a path expression. If SQL supported the syntax natively, it would look like this: All that is is convenience for a bunch of explicitly written LEFT JOIN expressions: ... Continue reading jOOQ 3.17 Supports Implicit Join also in DML -> ## Create Dynamic Views with jOOQ 3.17's new Virtual Client Side Computed Columns DevFeed: [Create Dynamic Views with jOOQ 3.17's new Virtual Client Side Computed Columns]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-06-30T14:46:35Z Content type: article Language: en Sources: [jOOQ]() Topics: [SQL](), [PostgreSQL]() Tags: [client-side-computed-columns](), [computed-columns](), [java](), [jooq](), [jooq-3-17](), [jooq-development](), [maven](), [sql](), [virtual-client-side-computed-columns](), [virtual-computed-columns]() ### AI overview This article explains jOOQ 3.17's client-side computed columns, which let developers define computed expressions that are substituted into SQL statements or evaluated when values are written. It contrasts them with server-side computed columns and discusses using the feature to create dynamic view-like behavior without database views. ### Source excerpt One of jOOQ 3.17's coolest new features are client side computed columns. jOOQ 3.16 already added support for server side computed columns, which many of you appreciate for various reasons. What's a computed column? A computed column is a column that is derived ("computed") from an expression. It cannot be written to. It works like ... Continue reading Create Dynamic Views with jOOQ 3.17's new Virtual Client Side Computed Columns -> ## 3.17.0 Release with Computed Columns, Audit Columns, Pattern Matching, Reactive Transactions and Kotlin Coroutine Support DevFeed: [3.17.0 Release with Computed Columns, Audit Columns, Pattern Matching, Reactive Transactions and Kotlin Coroutine Support]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-06-22T15:15:05Z Content type: release Language: en Sources: [jOOQ]() Topics: [releases](), [SQL](), [Kotlin](), [reactive](), [Transactions]() Tags: [audit-columns](), [client-side-computed-columns](), [computed-columns](), [coroutine](), [coroutines](), [implicit-join](), [java-17](), [jooq](), [jooq-3-17](), [jooq-development](), [kotlin](), [kotlin-coroutines](), [pattern-matching](), [postgresql](), [r2dbc](), [reactive-programming](), [reactive-transactions](), [release](), [release-notes](), [sql](), [stored](), [stored-computed-column](), [udt](), [virtual](), [virtual-computed-column]() ### AI overview The jOOQ 3.17.0 release adds client-side computed columns for read and write operations, audit columns, pattern-matching SQL transformations, and more implicit JOIN capabilities. It also sets Java 17 as the baseline for the Open Source Edition while commercial distributions continue supporting Java 8 and 11. ### Source excerpt This release contiues the work from previous releases around more sophisticated SQL transformation capabilities, including: Client side computed columns for both read and write operations Audit columns Pattern matching SQL transformations More implicit JOIN capabilities Client side computed columns A ground breaking new core feature available in all commercial distributions isthe new client side computed ... Continue reading 3.17.0 Release with Computed Columns, Audit Columns, Pattern Matching, Reactive Transactions and Kotlin Coroutine Support -> ## The Performance of Various To-Many Nesting Algorithms DevFeed: [The Performance of Various To-Many Nesting Algorithms]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-06-09T10:15:50Z Content type: article Language: en Sources: [jOOQ]() Topics: [Benchmark](), [SQL](), [Databases](), [Object-relational mapping]() Tags: [benchmark](), [benchmarks](), [database](), [java](), [jooq](), [jooq-development](), [json-arrayagg](), [many-to-many](), [multiset](), [mysql](), [nested-collections](), [one-to-many](), [oracle](), [ordbms](), [performance](), [postgresql](), [sql](), [sql-json](), [sql-server](), [sql-xml](), [test-data]() ### AI overview This article benchmarks several approaches to nesting to-many relationships with jOOQ, including MULTISET emulation, single joins with client-side deduplication, and multiple queries per nesting level. It reports that these approaches outperform the N+1 approach, with relative performance depending on data size and use case. ### Source excerpt It's been a while since jOOQ 3.15 has been released with its revolutionary standard SQL MULTISET emulation feature. A thing that has been long overdue and which I promised on twitter a few times is to run a few benchmarks comparing the performance of various approaches to nesting to-many relationships with jOOQ. This article will ... Continue reading The Performance of Various To-Many Nesting Algorithms -> ## Changing SELECT .. FROM Into FROM .. SELECT Does Not "Fix" SQL DevFeed: [Changing SELECT .. FROM Into FROM .. SELECT Does Not "Fix" SQL]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-05-31T08:39:55Z Content type: opinion Language: en Sources: [jOOQ]() Topics: [SQL](), [ordering](), [Databases](), [Programming]() Tags: [jooq](), [jooq-development](), [operations](), [order-of-operations](), [rdbms](), [sql](), [sql-syntax](), [syntax]() ### AI overview The article examines the difference between SQL's lexical order, such as SELECT .. FROM, and its logical order of operations, such as FROM .. SELECT. It argues that changing the syntax would improve logical consistency but would not fully fix SQL, and discusses jOOQ's support for alternative forms and variations across database systems. ### Source excerpt Every now and then, I see folks lament the SQL syntax's peculiar disconnect between the lexical order of operations (SELECT .. FROM) the logical order of operations (FROM .. SELECT) Most recently here in a Youtube comment reply to a recent jOOQ/kotlin talk. Let's look at why jOOQ didn't fall into this trap of trying ... Continue reading Changing SELECT .. FROM Into FROM .. SELECT Does Not "Fix" SQL -> ## Setting the JDBC Statement.setFetchSize() to 1 for Single Row Queries DevFeed: [Setting the JDBC Statement.setFetchSize() to 1 for Single Row Queries]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-05-11T08:55:41Z Content type: article Language: en Sources: [jOOQ]() Topics: [Benchmark](), [Databases](), [rdbms]() Tags: [benchmark](), [db2](), [fetch](), [fetch-size](), [fetchsize](), [jdbc](), [jooq](), [jooq-development](), [mysql](), [ojdbc](), [optimisation](), [oracle](), [postgresql](), [rdbms](), [sql](), [sql-server]() ### AI overview This article examines whether jOOQ should call JDBC Statement.setFetchSize(1) by default for queries expected to return at most one row. It proposes measuring the effect with a JMH benchmark and discusses limitations on comparing execution speed across RDBMS. ### Source excerpt An interesting hint by Vladimir Sitnikov has made me think about a new benchmark for jOOQ: The benchmark should check whether single row queries should have a JDBC Statement.setFetchSize(1) call made to them by default. The Javadoc of the method says: Gives the JDBC driver a hint as to the number of rows that should ... Continue reading Setting the JDBC Statement.setFetchSize() to 1 for Single Row Queries ->