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.
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.
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.
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.