Hi Antonio, 2015-04-18 13:41 GMT+02:00 Antonio Gallo <[email protected]>:
> 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 > Yes, that's true. jOOQ's current support for JPA annotations is very limited. In fact, we only chose JPA annotations because those are probably already on your class path (instead of implementing yet another set of annotations). > 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 :) ) > We have to be extremely careful here, and I will need to place a disclaimer - just in case. *jOOQ will never replace the Criteria API much like SQL will never replace JPQL*. I will use SQL as a synonym for jOOQ and JPQL as a synonym for Criteria API from now on. With JPQL, you're querying the object graph, i.e. the entities. JPQL has been kept extremely limited in functionality for good reasons. When querying the object graph, for instance, a UNION simply doesn't make any sense. Neither does a derived table, because the derived table can only ever materialise full entities, not arbitrary projections. This is also what Vlad meant (I suspect), when he referred to SQL as being ideal for "table-view" or "data-grid" projections. So, let's repeat: - With SQL, you will NOT query the object graph. - Thus, SQL is NOT an equivalent replacement for JPQL. - Thus, jOOQ is NOT an equivalent replacement for the Criteria API. I'm sure we're on the same lines of thought, here, but I have to say this, just to be sure I can link back to this discussion later on :-) (e.g. when someone else finds this discussion via Google) Now, since you *know* the above, you *can* use jOOQ to generate native SQL and let the EntityManager (or Hibernate Session) materialise entities from such results, either directly via EntityManager.createNativeQuery(String, Class), or indirectly via EntityManager.createNativeQuery(String, String) i.e. via @SqlResultSetMappings (if you must). I'm curious if you will make better query decisions than Hibernate, directly. Would be interesting to learn more about that. > 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. > Yes, I agree that this might be useful in some situations. > 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). > Are you sure? Maybe with JPA 2.1 @NamedEntityGraph (behold of the www.annotatiomania.com that is involved with using those) > I will publish soon the project (actually called jooq4hibernate) in a > public BitBucket repository and i'll share the link with you. > Wonderful! Looking forward. > 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). > Sure, I can. As soon as you tell me what exactly those problems were :-) Cheers, 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
