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 something to get a count, and then shortly thereafter
call .list() on the same Criteria. At first I thought that a count
wasn't the same as a sum; I want the count of all records matching the
criteria without respect to a specific property of the class whereas a
sum is typically of a specific property (or properties...). But now I
think that the count projected to a particular property would still
yield the same result, no? But isn't the projection redundant?
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").
If I understand correctly, in Michael's first example you would call a
projection method on a particular property and then call the
aggregation method on whatever it returned, so what would it return? Would it still be a Criteria? If it would still be an instance of
Criteria why would you need to call the projection method at all? How
about passing the property to the .aggregate() method instead? Like:
session .createCriteria(Some.class) .add(Expression.eq("any", value) .aggregate(Aggregate.SUM, "property")
If we include projection for aggregates, it should be no problem to make projection available for the list result. So there would still be the need for a "project" method. Don't like that.
How about if the Criteria had an .aggregate() method which returned and instance of Aggregate which had signatures for the various desired functions? Something like this would then be possible:
Criteria criteria = session.createCriteria(Some.class) .add(Expression.eq("any", value); Aggregate aggregate = criteria.aggregate(); Double sum = aggregate.sum("property"); Double avg = aggregate.avg("property"); long count = aggregate.count(); // would "property" be needed here? List objects = criteria.list();
Ugly. And not very extensible.
Would something like this cause problems with how Criteria works? I realise that it might not be as chainable as some might like but it would allow multiple calls for different things without having to build more than one Criteria.
Do aggregates need to be chainable? Would you want or need to do something where aggregate methods return Aggregates like criteria methods return Criterias?
If in Michael's example you could do something like the following, without it affecting the results of .list(), then I think it would meet my present needs (assuming it applied to count as well):
Criteria criteria = session.createCriteria(Some.class) .add(Expression.eq("any", value); Double sum = criteria.project("property") .aggregate(Aggregate.SUM); List objects = criteria.list();
Actually that is not such a bad idea ... imho aggregating does not need to be chainable. max(sum(xxx)) does not make sense without grouping, which is not available in the Criteria API (should it ever be?).
If it works to make aggregate execute the query without leaving any traces in the criteria we could do
Integer count = criteria.project(xxx).aggregate(Aggregate.COUNT);
This would still not solve the "want to reuse my criteria" issue. I don't have a good idea yet on how this could be done cleanly. Probably a clearProjection() method or something so one could do
Integer count = criteria.project("xxx").aggregate(Aggregate.COUNT);
criteria.clearProjection();
criteria.list();Don't know, not really perfect.
Michael
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
