jOOQ as a “PL/Java” language

Some people who get in touch with PL/SQL, PL/pgSQL, T-SQL, or any other proprietary procedural language for SQL interaction are probably missing out on a couple of language integration features in the Java world. Most Java APIs see SQL as an external domain-specific language that is “best” dealt with using string concatenation. Such APIs include:

Other APIs aim to abstract SQL away, in favour of a “higher-level” mapping to objects. These, again, include

As can be seen quickly, a lot of tool vendors and developers have travelled down similar ORM roads to try to tackle the “mapping problem” from a slightly (never fundamentally) different approach.

But not all people want ORM. Many people want SQL. A nice, general opinion about the old ORM vs. SQL discussion was phrased by Ken Downs a while ago:

SQL as an internal domain-specific language

We can all agree that SQL itself is a domain-specific language, a language specific to the domain of database querying and database manipulation. As mentioned before, SQL is enhanced on some platforms by proprietary, procedural extensions, some of which even made it into the SQL standard (although barely implemented in the standard form, apart from HSQLDB).

The main advantage of such procedural SQL language extensions is the fact that imperative control flow can be combined with declarative SQL statement execution. Both language paradigms have their place. One is ideal to model control flows, the other is ideal to model queries, abstracting boring querying algorithms.

But imperative programming is quite limited itself. It is difficult to profit from advantages offered by object-oriented or functional paradigms, implemented by popular languages like Java or Scala. Those who have tried Oracle PL/SQL’s “object-oriented” extensions may know what I mean. Furthermore, each procedural extension is vendor-specific and has its own learning curve.

jOOQ models SQL as an internal domain-specific language in Java, and can thus be seen as enhancing Java with some procedural aspects. This has been shown previously on this blog, through an example using H2 database triggers, written in Java/jOOQ. What was meant to be a proof of concept and a nice idea was now re-created by Ronny Guillaume, who wrote an interesting article (in French) about using jOOQ as PL/Java within a Postgres database! The article can be seen here:

In essence, you can use another third-party tool called pljava, compile and wrap jOOQ code into a jar file and deploy that jar file into your Postgres database before using it in regular Postgres SQL, or as a trigger. Similar things can be done in Java databases, such as Derby, H2, and HSQLDB, and even in the Oracle database (for the brave among you).

Looking forward to finding more interesting articles about using jOOQ for PL/Java in the wild!

10 thoughts on “jOOQ as a “PL/Java” language

  1. This is exactly what I was looking for!
    Thanks for linking that article. It’s a great write up. I’ll try and use this combination in a future postgres project.

    Do you know if
    Connection conn = DriverManager.getConnection(“jdbc:default:connection”);

    reuseses the connection that pljava creates, or does it make a new connection?

    1. Thanks for your comment. I’m not sure what you mean. If there’s a product called “pljava”, then that’s a coincidence. This article isn’t talking about such a product.

        1. Oh, I see, thanks for the pointer. It’s been a while :) I actually don’t know the answer. Perhaps, you could contact the author of pljava directly?

          1. ohh wow I didn’t notice this was written in 2013! I’ll contacting the author of that article. Thanks for all the great work!

  2. Probably not entirely on topic. But regarding your tweet about MySQL block support:

    Is it somehow possible to drop procedure from inside of that stored procedure to get effect like:

      -- anything
    prepare s from 'drop procedure  p';  -- This command is not supported in the prepared statement protocol yet
    execute s;
      deallocate prepare s;
    CALL p(); -- and it is already cleansed

    It is a concept of “self-droping” – disposable after first use. Or maybe a temporary stored procedure that will vanish when session ends?

    1. Interesting, thanks. That improvement might prevent some stale procedures lying around in some error edge cases where the drop command doesn’t get executed for some reason… I’ve noticed that occasionally in our integration tests

    2. … however, we’re thinking of creating these auxiliary procedures and not dropping them immediately, in the future. In a way, we’d be caching the logic on the server side, which would probably be helpful if the logic tends to be big.

Leave a Reply