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 2017-09-07 9:53 GMT+02:00 <[email protected]>: > 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 > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
