When paginating results in SQL, we use standard SQL OFFSET .. FETCH or a vendor specific version of it, such as LIMIT .. OFFSET. For example: SELECT first_name, last_name FROM actor ORDER BY actor_id OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY As always, we're using the Sakila database for this example. This is rather … Continue reading Calculating Pagination Metadata Without Extra Roundtrips in SQL
Simulating Latency with SQL / JDBC
I've run across a fun little trick to simulate latency in your development environments when testing some SQL queries. Possible use-cases including to validate that backend latency won't bring down your frontend, or that your UX is still bearable, etc. https://twitter.com/gunnarmorling/status/1361061234569805832 The solution is PostgreSQL and Hibernate specific, though to doesn't have to be. Besides, … Continue reading Simulating Latency with SQL / JDBC
Translating Stored Procedures Between Dialects
In the past years, we've invested a lot of effort into improving our procedural language capabilities in jOOQ. What started with a simple internal API to support the emulations of DDL clauses like these: -- Some dialect that supports this create table if not exists t (i varchar(10)); -- Db2 begin declare continue handler for … Continue reading Translating Stored Procedures Between Dialects
Implementing a generic REDUCE aggregate function with SQL
So, @rotnroll666 nerd sniped me again. Apparently, the Neo4j Cypher query language supports arbitrary reductions, just like any functional collection API, oh say, the JDK Stream API: Stream.of(2, 4, 3, 1, 6, 5) .reduce((i, j) -> i * j) .ifPresent(System.out::println); // Prints 720 SQL doesn't have this, yet it would be very useful to be … Continue reading Implementing a generic REDUCE aggregate function with SQL
jOOQ Internals: Pushing up SQL fragments
Over the past 13 years, jOOQ has accrued quite some internal features, which you, the user, are not exposed to. One very interesting feature is the capability for any arbitrary jOOQ expression tree element to push a SQL fragment up to a higher level. How does it work? The jOOQ expression tree model When you … Continue reading jOOQ Internals: Pushing up SQL fragments
Automatically Transform Oracle Style Implicit Joins to ANSI JOIN using jOOQ
While jOOQ is mostly being used as an internal SQL DSL for embedded, dynamic SQL in Java, where it offers the best solution on the market, jOOQ is increasingly also used for one of its secondary features: Its parser. Having been introduced in jOOQ 3.9 primarly for the purpose of being able to parse DDL … Continue reading Automatically Transform Oracle Style Implicit Joins to ANSI JOIN using jOOQ
jOOQ 3.14 Released With SQL/XML and SQL/JSON Support
jOOQ 3.14 has been released with support for SQL/XML, SQL/JSON, Kotlin code generation, embeddable types, and domain types, synthetic constraints, better MERGE support, and more SQL transformations. In this release, we've sorted our github issues according to user feedback and finally implemented some of the most wanted features, which include better Kotlin support, embeddable types, … Continue reading jOOQ 3.14 Released With SQL/XML and SQL/JSON Support
Using jOOQ 3.14 Synthetic Foreign Keys to Write Implicit Joins on Views
jOOQ has supported one of JPQL's most cool features for a while now: implicit joins. Using jOOQ, you can navigate your to-one relationships in a type safe way, generating LEFT JOIN operations implicitly without the effort of having to keep thinking about join predicates, and the correct join order. Consider this Sakila database query here, … Continue reading Using jOOQ 3.14 Synthetic Foreign Keys to Write Implicit Joins on Views
Nesting Collections With jOOQ 3.14’s SQL/XML or SQL/JSON support
One of the main features of ORMs is M as in Mapping. Libraries like jOOQ help auto-mapping flat or nested database records onto Java classes that have the same structure as the SQL result set. The following has always been possible in jOOQ, assuming PostgreSQL's INFORMATION_SCHEMA (using the generated code from the jOOQ-meta module): class … Continue reading Nesting Collections With jOOQ 3.14’s SQL/XML or SQL/JSON support
Having “constant” columns in foreign keys
I was asked a very interesting question on Twitter just now: https://twitter.com/connolly_s/status/1303957373107818497 Can we have "constant" foreign key columns in (PostgreSQL) tables? Luckily, yes, we can. Using a nice standard feature that is "computed columns" or "generated columns" Sometimes, you cannot completely normalise your schema for whatever reason. There may be a case where you … Continue reading Having “constant” columns in foreign keys