My appologies if this reply message was sent incomplete once already.
> > How about if the Criteria had an .aggregate() method which returned
> > an instance of Aggregate which had signatures for the various
> > desired functions? Something like this would then be possible:
> >
> > Criteria crit
...
> I don't see this a big problem. Essentially, count() is the only
> aggregation function that makes sense without projection. So I think
> it is acceptable to have something like
> project("id").aggregate("count").
I don't see it as a problem per say, I just thought it was redundant,
but if
Hi,
This proposed code seems to me to work on the premise that any
aggregate function will be performed against a particular property.
Which makes logical sense if you want the sum of a particular property
as exampled above. My concern has always been that I want to build one
Criteria, call some
Okay, I've reviewed the following thread (thank-you to Christian for
refreshing my memory) and given it some thought. I would like to
discuss some thoughts and questions and just generally try to continue
the brainstorming...
> http://thread.gmane.org/gmane.comp.java.hibernate.devel/4795
> Just
On 01 Mar (09:57), Greg Handi wrote:
> Personally I don't think the patch sucks, I just think that having TO
> patch anything sucks especially when this seems like core functionality
> that ought to be available.
Guys, this is open source. Michael made two suggestions months ago, when
we discusse
Personally I don't think the patch sucks, I just think that having TO
patch anything sucks especially when this seems like core functionality
that ought to be available.
I too would be happy to help in any way I can to get something that
would meet this need and be included in the Hibernate distri
