I do think there’s a gap between hibernate and jooq that needs filling. I love the ease of querying for relational data with hibernate, along with support for validation annotations. On the flip side I love the jooq dsl, code gen, typed queries, and the flexibility you get from it, but there’s really no easy way to plug in validation annotations and querying for nested relational data requires a lot of effort. Based on a brief look of the docs, it seems like this library intends to fill that exact niche. Interested in checking it out when I get some time

[–] lars@programming.dev 2 points 1 year ago (1 children)

From a cursory look (I'm on my phone), it seems like a worse version of JOOQ. But I'd be interested in seeing a comparison of their relative strengths and weaknesses.

JOOQ generates code by looking at your schema (either the real database or schema files on disk), whereas it looks like this one uses "dto" files which I'm not familiar with. But could be that it offers more control about how to handle rolling out a new change.

[–] lorefnon@programming.dev 1 points 1 year ago

I like jooq, but after using it in a few projects, I now personally feel an Entity centric approach where you control domain objects rather than have them generated fits in better in the java/kotlin ecosystem where sooner or later you'll also need to add other annotations to the entities for jackson/spqr/microprofile-graphql etc.

Doing this with jooq is possible (given support for custom projections etc.) but it requires significantly more boilerplate as jooq is first and foremost a db-first library.

Having first class support for association loading etc. is also quite helpful esp. for crud-heavy applications as opposed to the jooq approach of staying closer to sql without abstractions. ymmv of course.