JOOQ code generation strategy across multiple branches

One issue that I would like to avoid is two branches updating the JOOQ generated code. I imagine that this can lead to a messy merge conflict. Is there a best-practices strategy for managing DB changes across two different branches with JOOQ?

Solution

Future jOOQ multi schema version support

Multi schema version code generation is coming in a future release with https://github.com/jOOQ/jOOQ/issues/9626

Work on the required infrastructure for the above has started in jOOQ 3.15. There's a lot of work and open questions, but eventually, it will be possible to define a set of source schemas which should all be supported at the same time:

By code generation
By the runtime (e.g. * includes only columns available in a given version)

Rolling your own using SQL views

Until then, you might be able to pull off a compatibility layer yourself using views. For example:

-- Version 1
CREATE TABLE t (
  id INT PRIMARY KEY,
  col1 TEXT,
  col2 TEXT
);

-- Version 2
CREATE TABLE t (
  id INT PRIMARY KEY,
  -- col1 was dropped
  col2 TEXT,
  -- col3 was added
  col3 TEXT
);

Now deploy a view that looks the same to your client code for both versions:

-- Version 1
CREATE OR REPLACE VIEW v (id, col1, col2, col3) AS
SELECT id, col1, col2, NULL
FROM t;

-- Version 1
CREATE OR REPLACE VIEW v (id, col1, col2, col3) AS
SELECT id, NULL, col2, col3
FROM t;

If your RDBMS supports updatable views, you might be able to use them like any other table, especially when adding synthetic primary keys / synthetic foreign keys to your generated code.

With a generator strategy, you could further rename your generated view names V to T (assuming you exclude the actual T from being generated), and your client code won't even notice that you emulated the T table with a view.