Clean separation of generated POJOs and jOOQ records

817 views
Skip to first unread message

Adam Gent

unread,
Aug 31, 2016, 12:28:42 PM8/31/16
to jOOQ User Group
Call me an old school Java developer but I like layers of separation.
I like the generated POJO classes to be decoupled as possible and they fairly are but...

The current code generator will do several things I don't like. 

1. Make POJO classes with the exact same name as the Table objects.
2. I don't like having POJO in the package name. We use package names for all kinds of things (routing, metrics) so it is ugly to see pojo.
3. Mix the POJO classes in the same hierarchy as the Table / Record classes.
4. If using the Maven generator all of the above will be in the same Jar (ideally the pojos would be in their own jar).

Thus I have written a code generator that will put all the POJOs into a data package and everything else will go into an internal package.

com.mycompany.data <--- pojos live here
com.mycompany.internal <-- database tables (the subpackages are the same).


Sadly I haven't figured out an effective way to separate the classes into separate Jars easily with out rerunning the generator and doing some maven hacks.

However there are ways to exclude package names (ie ban other maven modules from using *.internal):


Lukas Eder

unread,
Sep 1, 2016, 3:15:44 AM9/1/16
to jooq...@googlegroups.com
Hi Adam,

These are interesting thoughts, thanks for sharing. In principle, you could override the GeneratorStrategy.getFile() methods to relocate the POJOs into a different .jar file. The method hasn't been designed for this purpose, so there might be 1-2 caveats, but in principle, that might be one other possible hack to do so.

Hope this helps,
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.

Adam Gent

unread,
Sep 1, 2016, 5:23:39 PM9/1/16
to jOOQ User Group
I can't recall why but I had some issue with GeneratorStrategy.getFile and the way I did it just turned out easier (for me).

The reason why the separation is nice because you can use the generated POJO for an internal API (aka microservices with a message bus).

This works particularly well since our services are protocol driven (that is the message aka POJO is the contract and not endpoints like REST/SOAP).

Consequently I make a maven submodule (or top level project) that has generates the POJO and jOOQ specific stuff.
Because I can't separate the classes out I make  jOOQ  as an optional dependency. It is not ideal because the generated jOOQ specific classes (Record, Table etc) crowds the name space but at least the compiler catches this (if your not using jOOQ in the client which we often are...).

This is why I make sure to append "Table" to the generated Table classes because it is very easy to accidental import them.

In the future we may just manage our POJOs independently and rely on MapStruct (http://mapstruct.org/ like ModelMapper but generated code). But then we are copying two times (Our POJO -> jOOQ POJO -> jOOQ Record). Not ideal but probably inconsequential to performance.

-Adam

To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.

Lukas Eder

unread,
Sep 2, 2016, 4:45:15 AM9/2/16
to jooq...@googlegroups.com
Interesting, thank you for the additional insight.

I'm not sure if I caught this correctly, but have you also tried running the code generator twice? Once without POJOs and once with POJOs only?

To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscribe@googlegroups.com.

Adam Gent

unread,
Sep 2, 2016, 10:29:49 AM9/2/16
to jOOQ User Group
I sort of mentioned it earlier but wasn't clear. I think you can generate without the POJOs but you can't generate the POJOs without the Table/Record classes. I will have to check on this though. 

The way I think I had tried with the Maven hacks is to run the generator twice, once in each maven submodule and then using my naming scheme remove the package named "com.mycompany.db.internal" with the Jar plugin (or maybe it was the assembly plugin... I can't recall).
 
To be clear and honest though I don't think it is worthwhile changing jOOQ for this behavior. I brought it up as a talking point and to maybe see what others are doing.
 
I think the better solution is for folks to make their own  domain objects by initially opening up the generated POJOs and copying/pasting the contents to a new class and then using MapStruct to map their POJO to jOOQ's POJO. MapStruct will even check if you missed fields.

Yeah you have to run code generators but such is the life of Java. Generated code is highly underrated compared to metaprogramming (ruby) are extreme type magic (scala).

Lukas Eder

unread,
Sep 4, 2016, 3:14:28 PM9/4/16
to jooq...@googlegroups.com
2016-09-02 16:29 GMT+02:00 Adam Gent <adam...@snaphop.com>:
I sort of mentioned it earlier but wasn't clear. I think you can generate without the POJOs but you can't generate the POJOs without the Table/Record classes. I will have to check on this though. 

Oh, interesting, I haven't thought of this. You're right, it's currently not possible to turn off the generation of tables. I've created a feature request for this:

Thanks for pointing this out!
 
The way I think I had tried with the Maven hacks is to run the generator twice, once in each maven submodule and then using my naming scheme remove the package named "com.mycompany.db.internal" with the Jar plugin (or maybe it was the assembly plugin... I can't recall).

Indeed, that would work too, but I can see how this doesn't "look right".
 
To be clear and honest though I don't think it is worthwhile changing jOOQ for this behavior. I brought it up as a talking point and to maybe see what others are doing.

Why not? :) I think you've discovered a flaw, and it's perfectly fine to fix it. Almost everything else can be turned on/off in the code generator...
 
I think the better solution is for folks to make their own  domain objects by initially opening up the generated POJOs and copying/pasting the contents to a new class and then using MapStruct to map their POJO to jOOQ's POJO. MapStruct will even check if you missed fields.

I'd love to hear others' opinion on this, too.
 
Yeah you have to run code generators but such is the life of Java. Generated code is highly underrated compared to metaprogramming (ruby) are extreme type magic (scala).

It's a pragmatic approach to a real-world problem. I've played with type providers. They're dangerous tools and very obscure to debug. Nice when they work, but sometimes, they don't work...

Thanks a lot for your feedback!
Lukas 
Reply all
Reply to author
Forward
0 new messages