Generate classes for keys with jOOQ

The jOOQ feature on the roadmap

You're not the first one with this idea. There's a pending feature request to generate such "key wrapper" classes out of the box (not available in 3.11 yet): https://github.com/jOOQ/jOOQ/issues/6124

Or this discussion: https://groups.google.com/forum/#!topic/jooq-user/53RZqoewa3g

There are additional applications to yours for this feature. Once such types exist:

• You can only join by matching primary keys / foreign keys, as they would no longer be modelled by arbitrary numeric types
• It will be impossible to forget a column in a composite key when joining or filtering, as the composite key will become one value

The composite key case is the one that makes this tricky for jOOQ to support out of the box, as a variety of additional features needs to be implemented first in order to group several columns into a synthetic column. Also, both unique keys and foreign keys can overlap, so there are quite a few edge cases that have to be taken into account.

Implementing it yourself

You can implement this yourself. If your schema only has single column surrogate keys, then you could override the JavaGenerator class and generate an additional class per table and add the relevant forcedType configurations and Converter implementations programmatically to your code generator configuration.

Others may have done something like this, but I'm not aware of any publicly available implementation.

Implementing it in the database

In principle, you could also implement this in the database directly, e.g. if you're using PostgreSQL. You could wrap your UUID in a composite type and use that for your primary keys / foreign keys:

create type pk_a as (id bigint);
create type pk_b as (id bigint);

create table t_a(id pk_a primary key);
create table t_b(id pk_b primary key, a pk_a references t_a);

insert into t_a values(row(1)::pk_a);
insert into t_b values(row(2)::pk_b, row(1)::pk_a);

The jOOQ code generator should pick up these types and do the right thing for you. Of course, there are probably quite a few caveats, given that I've hardly ever seen this practice in the wild :-)