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 <snippit from Michael's post in above thread...> > Just some brainstorming: > > As of yet, you can only query for mapped classes, so only count() > makes really sense ... MIN, MAX, SUM and AVG are all only useful if > we can query for properties using the criteria api. So introducing > one without the other would be not very useful. > > If you restrict it to one property queried, off my head I could > imagine something like > > session > .createCriteria(Some.class) > .add(Expression.eq("any", value) > .project("property") > .aggregate(Aggregate.SUM) > > or > > session > .createCriteria(Some.class, "property") > .add(Expression.eq("any", value) > .aggregate(Aggregate.SUM) > > I would keep the Criteria API returning just a List, not returning > multiple Object arrays, not returning multiple properties. 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? If I understanf 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") Now although .aggregate(Aggregate.COUNT, "property") should yield the same result as .count() isn't it a bit pointless in the counting scenario? How about if the .aggregate() method also had the single argument signature and threw and exception if it needed a specific property? I don't think throwing Exceptions to define usage like that would be clean but I'm just "thinking out loud". In Michael's second example the creation of the Criteria seems tied to projecting on a particular property, wouldn't this then limit what could be returned to only aggregate function results? It seems to me that this would potentially eliminate the ability to first call something for a count and then call .list() for the instances of the desired class? 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(); 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(); What about using the aggregation within the Criterion? I don't personally need to do this but I'm just wondering if it is desireable functionality? I guess it could always be accomplished by getting the result and then using it to continue building the Criteria if people don't mind not having one long unbroken chain of method calls (which personally I don't like anyway because when you screw up you get a largely useless stack trace blaming the first call). Thank-you all for your time reading and (hopefully) discussing. __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com ------------------------------------------------------- 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
