Translating Stored Procedures Between Dialects
So many SQLs, so little time.
Join the DZone community and get the full member experience.Join For Free
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:
… evolved into a full-fledged API for all sorts of procedural logic executed in your database server.
The above examples show what most RDBMS call “anonymous blocks”, similar to Java’s anonymous classes, i.e. elements of procedural logic that do not have a name.
Depending on the database, these blocks are interpreted on the fly, or compiled and cached like ordinary SQL statements. They can be very useful for a variety of reasons:
- To create atomic ad-hoc units of code, executed in a single server round trip, similar to the above DDL scripts with integrated exception handling
- To create dynamic procedural code. This may be esoteric for many, but exactly the right thing to do for others. All of jOOQ is about dynamic SQL, so why not also dynamic PL/SQL, T-SQL, pgplsql, etc?
- To work around limitations imposed by Conway’s Law, when there is no way you can get the necessary GRANT or other bureaucratic token to deploy your procedure in production at your discretion. I mean, this is still a thing in a lot of companies.
- A lesser case of Conway’s Law may be when you’re a product vendor, and you don’t know if you can create procedures on your clients’ production system. Just don’t. Run your procedural logic as an anonymous block if you can’t, or as a procedure if you can. Same jOOQ code.
- If your procedural code changes very frequently (even dynamically), storing it might cause tricky issues. If you’ve ever worked with Oracle and ran into the dreaded latch-free event, you know what I mean.
I’m by no means advocating you should use anonymous blocks over stored procedures in general. If you can, store your code in the database for better performance and re-use. But sometimes you can’t, and sometimes you shouldn’t.
So, jOOQ supports – as always – a mix of various procedural logic elements, including:
- Blocks with variable declarations
- Loops including
ITERATE) for loop control flow
RETURNto return from procedures or functions
CALLstatement to call other stored procedures
EXECUTEstatement (for running dynamic SQL from within procedural logic. Which level of inception is that?)
And we’re adding more support all the time. The Java code might look something like this:
Assuming you cannot run a bulk insert statement for some reason, this might be the way to go. It translates to various dialects as follows.
Db2 and MySQL (which doesn’t support anonymous blocks, but statement batches)
As always with jOOQ, you don’t have to start out with writing jOOQ API based code. While this is the recommended approach when your procedural (or SQL) logic is dynamic, jOOQ can also parse and translate static SQL in string form. The babelfish of SQL. Play around with it here to learn more: https://www.jooq.org/translate/
Storing the Code as a Procedure
If you don’t have any of the above use-cases, you will want to store this code as a procedure (or function):
- For greater re-use
- For better performance
CREATE PACKAGEis high on our wish list, but might not make it into 3.15 anymore. If packages are used for namespacing only, they might be emulated using schemas in other dialects. Other package level features, such as package state may be more difficult to translate.
The previous anonymous block can be easily wrapped in a
Which would produce the following procedures:
Db2 and MySQL
Procedural languages are standardised via the ISO/IEC 9075-4 standard, and some RBDMS surprisingly agree to a large extent on the standard, including:
Others do less so, but all procedural languages agree on the fact that they are very simple languages, without any such “fancy” things like subtype or parametric polymorphism (OK, PL/SQL has some subtype polymorphism, but not a very sophisticated one. We won’t support it for now), lambda expressions, dynamic dispatch, algebraic data types, etc. etc.
What they do have in common is a tight integration with the SQL language, which is where they shine.
But there are subtle differences, nonetheless. For example, they differ in where you can declare variables. Some have block scope, others don’t. And some adhere to the standard, where
LEAVE requires a label, others don’t.
Imagine you write this “fantasy” jOOQ code
This is just a more complicated version of the original loop, which inserts values 1-10 into a table. There’s no reason other than to show off the transformation capabilities for the nesting of
loop(exit()), as well as the infinite
EXIT usage, rather than the indexed
There are a few things that don’t always work exactly like this in some dialects!
Let’s look at what Db2 does with this.
If we don’t use
EXIT on a loop, then there won’t be a label. Or, you can obviously label your loops explicitly, which is always recommended. But sometimes, you don’t have that in your original source code.
What does Oracle do with this?
Oracle has a slightly different syntax here:
The main difference being that the declaration is also pulled up, but a separate
DECLARE block is required to declare variables outside of
BEGIN .. END. Label-less
EXIT is supported natively, so nothing needs to be transformed here.
Whether you’re migrating off one dialect onto another, or whether you’re supporting several dialects at once, or you’re writing dynamic SQL and dynamic procedural logic, or you just like writing things in Java rather than native SQL, or you suffer from Conway’s Law and cannot store your procedural code easily, jOOQ can help you with those endeavours.
For a while now, jOOQ has supported procedural statements as anonymous blocks for the most popular dialects. Starting from jOOQ 3.15, we’ll also support storing this logic in the database in a dialect agnostic way, as well as parsing / translating procedural code on our website, or as a library / CLI or JDBC proxy to replace your SQL / procedural code ad-hoc in a legacy JDBC application.
Stay tuned for more in this exciting area of jOOQ development!
Published at DZone with permission of Lukas Eder, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.