Hi Lukas, You are right, I've abused of "business logic" term :p
Surely you can move any business logic into the query. For services that I built from scratch, I use only jooq implementing complex query (with a lot of business logic on top of it) Let me explain a bit more what I mean. We introduced jooq on an already running system, so we had to maintain and evolve a 100% hibernate software (with a lot performance issues). Many of the business logic was already built in Java layer: object graph navigation, state machine management, also a pure object filtering! The problematic scenario was that Java layer use a lot the "transparent" aspect of an orm, and in particular the lazy fetching feature. When we try to replace the hibernate dao (unmaintenable queries using hibernate criteria) with ad hoc optimize jooq query, we faced out that another piece of code used that method to retrieve the same BUT then it navigate a different part of objects graph. In conclusion, If you have a lot of Java logic traversing your entities and your code rely heavily on orn lazy fetching, using jooq to replace the native orm behavior is a game over. If you fetch from db _all_ data you need to perform any business logic you can safely replace orm queries with jooq, but you have to deal with mapping. In both scenarios jooq support for jpql would be great, but I see technical problems (maybe it requires a new discussion) If you need a pure relational feature, like report, you have to use jooq. Regards Daniele -- 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.
