Digest for jooq-user@googlegroups.com - 4 updates in 1 topic

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Digest for jooq-user@googlegroups.com - 4 updates in 1 topic

http://groups.google.com/group/jooq-user/topics mailing list
[hidden email]: Sep 07 12:53AM -0700

Hi all,
Has anyone tried to build type-safe IDs with jOOQ?
Something like described e.g. here:
(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?
Hilco Wijbenga <[hidden email]>: Sep 07 08:55AM -0700

Hey Nikola,
> whole codebase easily
> The only boilerplate could be in XML specifying all the converters.
> Am I missing any roadblocks?
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.
Lukas Eder <[hidden email]>: Sep 07 06:10PM +0200

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.
Lukas Eder <[hidden email]>: Sep 07 06:16PM +0200

I suggest you hook into the code generation by generating a custom code
section in each table:
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,
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].