Hi Lukas,
thank you, if it's really work (i have to write more tests on it and test with different version of Hibernate) I think that could be really interesting for jOOQ because it's truth that you always say that jOOQ don't replace JPA\Hibernate framework but can complement it, but it's also true that you can't use together but you have to use separetely because there isn't any kind of integration with those framework, and if you only use the fetchInto feature of jOOQ to fill the Entities, you don't work with the proxy so the entire ORM framework is useless from the point of view of lazy associations and stuff like this Regarding the Vlad observation, this project can be useful if you have an architecture completely based on Hibernate framework when the DAO Layer is coupled with Hibernate Entity (that is our case) and you want to take control of the DAO Layer replacing the Criteria API with query written in jOOQ. For us it could be really simple replace Criteria API because we can use a SQL wrapper to get the SQL Query, use the tool SQL 2 jOOQ to generate code base for jOOQ query, modify it and replace Criteria API with a call to the HibernateDSLContext (maybe here could be also interest to write an article if the prototype evolve in a good way :) ) You said that you prefer separate reading using jOOQ and writing using Hibernate\JPA, but what if you have a business method that read some data before write or update something based on what is read? If you can work with the entities also for the reading part (written in jOOQ), you can reuse the same objects to write or update those data. So in this scenario it can be really useful thinks in terms of Entities. It's also true that for other kind of reading, for example in the case of a complex report\view of data, thinks in terms of Entities is not so good instead is a really pain in the xxx, and in that case is obviously better using select with projections and specific bean to represent the data maybe 1-1 with the select fields. So i don't prefer entity graph instead of business-case projections, it's only that the best choise depends on what are you doing and for sure you can\have to use both approaches depending on the case. Finally i think that this project has a lot of application field. I can also think to develop a JPADslContext that is limited only to fetch the entity without any associations (unfortunately there isn't an API for that like in Hibernate). I will publish soon the project (actually called jooq4hibernate) in a public BitBucket repository and i'll share the link with you. I will also post my doubts and problems encountered using VisitListener of jOOQ (when the code will be available is better). Lucas you can eventually tell me how to handle certain things that actually i handle using reflection in the VisitListener (to extract some data, i had to study little pieces of jOOQ code to access it, also because the poor documentation of VisitListener). Stay tuned! Antonio -- 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.
