Hi there,

Just wondering if it's possible to decouple DetachedCriteria from SessionImpl? Explicity the cast from Session to SessionImpl in getExecutableCriteria(). This prevents using this functionality in environments that use Session delegators, such as nanocontainer-hibernate etc.

Also, is there a reason why getExecutableCriteria() doesn't return a cloned instance of Criteria each time? This would be very handy to append adhoc criterion to an attached criteria without modifying the original DetachedCriteria. For example:



Cheers,

Mark

Zero replies, OK let me simplify the problem.. ;)

There appears no way of cloning a Criteria - is there a good reason for this?

My use-case is as follows: I effectively have factory methods to return Criteria instances rather than using direct HQL, and would then like to page, order, count, etc the returned Criteria. Since additions to Criteria cannot be removed, I can only use a modified Criteria once & then have to re-request another from the factory to perform another operation. Ideally I'd like to request one Criteria & then produce the required number of clones to list pages, count totals etc.

I can't even reconstruct Criteria's by interrogating them since the API only contains add() methods and no get() methods.

Any comments?

Cheers,

Mark

The desire for cloned Criteria/DetachedCriteria has also been posted here and here.

I have a work-around for my current pagination issues, but as soon as I want to ADD ordering or searching functionality, I'll have to do something similar to return a new instance of the DetachedCriteria.

I actually don't even see why we should be needing to clone criteria. Each method that adds a criterion or sets a projection returns a Criteria. Now, I realize this was done to allow method chaining (criteria.add(...).add(...)... and so on). However, the documentation and the tutorials don't state clearly enough (to my simple mind at least) that these methods have the side effect of changing the orginal criteria.

In fact, even when you get the Executable Criteria from the DetachedCriteria, the DetachedCriteria instance is changed. It seems to me that having these methods have the side effect of changing the actual criteria, when a Criteria is already being returned, is a very confusing API choice. Getting rid of unclear side-effects would also solve the problem. However, if that's the more difficult route, implementing Cloneable is also a perfectly acceptable solution.

So, can anyone indicate to me whether or not one of us (the people recently requesting this behavior) should put this as an issue in JIRA? (Should it be considered a feature request or a bug? I'd guess FR, though the behavior seemed so unintuitive to me that I thought it was a bug at first...)

I have posted some code here
http://forum.hibernate.org/viewtopic.ph ... 54#2234254

I have implemented a DoubleCriteria which inder the hood manages two identical criteria instances. You can then use one for the list and the other for the count.

Also I have provided a CountDoubleCriteria class. It allows you to addProjection addOrder, setFirstResult, setLastResult, and only applies these to the first criteria, keeping the 'count' criteria instance in tact.

I also posted some code at http://forum.hibernate.org/viewtopic.php?t=939781 which clones a detached criteria using serialization. I did this so I could copy the criteria and modify the copy for rowCount, setFirstResult, etc. at different times for pagination. I would be curious to know if this solution is crazier than any others.

-gabe

Hi,
So what about the original question about decoupling DetachedCriteria from SessionImpl? I am also in an environment where I am using a delegator that comes from an IOC container and I am unable to use DetachedCriteria feature.

My delegator implements org.hibernate.Session and all my DAOs simply get a org.hibernate.Session interface to work through. Due to this I cannot create a getRealSession() method in my delegator and use that to work with DetachedCriteria because I do not want to create coupling in my DAOs.

Should this be logged as a bug or is there a workaround?

Thanks,
Igor

guys

you dont need to do the "double criteria" stuff.

After you get the row count, just do this (on the same Criteria):



.. and hey presto you can re-use the same criteria object.

HTH,
Ben

Guys,

I couldn´t found a workaround for this. Did anybody have it?
It´s true that, as beniji said, I could re-assign to the default ROOT_ENTITY
projection by setting ResultTransformer, but what about other things, like resetting maxResults or firstResults. It would be grate if I simple can reset CriteriaImpl.maxResults and CriteriaImpl.firstResults to null and re-execute the query, but I can´t how.
So at this moment the only way that works for me is to do the serialization process mentioned here:

http://forum.hibernate.org/viewtopic.php?t=939781&highlight=clone+criteria

But I think that here I´m loosing some speed.
Maybe I´m missing something, I´m new to hibernate, so if anyone knows a better solution, please let me know.

TIA
Daniel