I actually would love to know the answer, but I can tell you that this is possible you can actually do something like this to get a session :
Session = (Session) em.getDelegate();
Where em is a EntityManager.
Now the problem that I had is the Entities would become detached and I wouldn't be able to persist them back to the database after I changed somethings , It kep't seeing them as
updates, I was probably doing something stupid. I Honestly do prefer to use the Criteria queries, HQL .. is another learning curve for me...
Let me know what you think- Oh and I know that ....getDelegate() does not work in every single container...
I don't consider HQL as another learning curve, I think it's quite straightforward, specially if you know SQL. Entity relationships take all the join burden off, so HQL will only be used for filtering. What I want to avoid is all the low level issues like the one you say. In fact, I prefer adapting myself to
the suggested way to do thingsrather than struggling with all kind of problems because of my stubbornness.
My main reason for preferring criteria queries is because it makes it easier for me encapsulate filtering in one only DAO method, instead of writing HQL everywhere. Anyway, I see Seam discourages the view - service - dao layering, so it seems I should better change my mind.
Nothing in Seam prevents or discourages you from using the Hibernate criteria API. Quite the contrary, it is very simple to use. For example, we have extended EntityQuery to use the Criteria API.
Sorry to reopen this issue,
but I didn't quite get it. Are you talking about HibernateEntityQuery whose createQuery method use a getRenderedEjbql()?
If possible I'd like to know which components in Seam favors the use of hibernate criteria and among those components which of then permits paginating a result from a query, for instance.
I did not understand, are you talking about me having to extend what Seam offers to provide such functionality or Seam offers it nativelly?
Thanks in advance!
Sorry to take so long to reply.
In reading my previous reply, I realize that I may have made this sound simpler than it was. In fact, we replaced (a lot of) existing logic to obtain the result set. We did not need to make any changes to the paging, since that works on the existing result set, regardless of how it is produced.
Basically we used the approach mentioned by Dylan above to get the Hibernate Session, and then extended EntityQuery, overriding the getResultList method to use the Hibernate Criteria API. We also implemented parsing of request parameters in order to translate them into Criteria API calls.
Criteria API has been added to JPA 2.0 spec.