Type-safe IDs

[alam...@gmail.com]

Hi all,

Has anyone tried to build type-safe IDs with jOOQ? 

Something like described e.g. here:

https://dysphoria.net/2013/04/12/id-type-safety-in-database-code/

https://www.wix.engineering/single-post/on-identifier-types-type-safety-and-guids

(there are probably better articles about it - it is an age-old idea)

It looks to me it would not be that hard to do, given jOOQ already generates a bunch of useful code (for example a class for each table) and supports custom converters. Then the types would just propagate from records to the whole codebase easily

The only boilerplate could be in XML specifying all the converters.

Am I missing any roadblocks?

Thanks,

Nikola

[Hilco Wijbenga]

Hey Nikola,

I generate our IDs (one per table) by iterating through the fields in
the Tables class (i.e. the one generated by jOOQ). That makes it easy
to keep everything up-to-date. The mappings from value object to
Record (and back) are manually generated. Automating that is
substantially more complex.

I haven't gone quite so far as to actually change the jOOQ generated
code but, now that you mention it, I really should do that too. That
would also simplify the mappings. The problem, at least with my
current setup, is that I now have a chicken-and-egg problem. I use the
jOOQ generated code to generate the IDs but the converters (assuming
there is one per ID) would have to be generated too ... before I even
have the Tables class.

I believe there is some sort of Metadata object that would probably
work better but, if memory serves, Lukas mentioned that it wasn't
always reliable. I'll have to give it some thought.

Cheers,
Hilco

[Lukas Eder]

Hi Nikola,

Indeed, this useful feature has been on the roadmap for a while now, and with our upcoming JPA integration improvements (due for jOOQ 3.11), there is a high chance of this being implemented with:

- https://github.com/jOOQ/jOOQ/issues/2530

- https://github.com/jOOQ/jOOQ/issues/6518

One main reason why this hasn't yet been implemented is the difficulty of getting it right. Sure, a website like wix can easily add this feature to their homegrown ORM by simply asserting that all IDs are single-column surrogate keys. We unfortunately cannot. jOOQ supports all kinds of database designs, including situations where:

- A table has several composite candidate keys that potentially even overlap

- A column participates in several composite foreign keys as well

With this in mind, it won't be easy to replace the existing columns by some specific "ID" type. We'll have to generalise the idea into a sort of overlapping column group, which can be:

- auto generated from unique / foreign keys

- configured through the usual regular expressions

Specifically, the latter feature will somewhat correspond to the JPA @Embeddable / @Embedded feature (even if JPA doesn't allow for these types to overlap in terms of columns they include), and we'll support generating jOOQ code also from JPA-annotated @Embedded columns.

So, again, as you see - this is not as easy for jOOQ as it might be for some blogger out there, who needs to solve this only for their specific requirements. But it's certainly a *very* interesting feature that we'll look into implementing, soon.

Cheers,

Lukas

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lukas Eder]

Hilco,

I suggest you hook into the code generation by generating a custom code section in each table:

https://www.jooq.org/doc/latest/manual/code-generation/codegen-custom-code

In that section, you can easily automatically generate:

- The ID wrapper

- The Converter for the ID wrapper

Additionaly, you could switch to programmatic code generation and generate a <forcedType> configuration for each of your tables / primary keys to appy the mapping from the primary key column type (and the foreign keys too, of course) to the newly generated ID wrappers and their converters.

This will work:

- If all your primary keys are single-column keys

- If all your foreign key columns reference only a single primary key

Hope this helps,

Lukas