Hey everyone, Good to see this has come up again. Congrats on getting the GSoC selection Nicolas. The previous thread[1] has a lot of good discussion in it if anyone here wasn't following that.
Obviously, I prefer the expression object API. I've actually been using it a bit in an order processing app I'm working on. I've been keeping the patches up to date with qs-rf and I just merged it with the new trunk. If anyone wants to check them out, where should I put them, as an attachment on #3566? (It works a bit differently than what's described here, folding all the behavior into values(), which might not be ideal) [1]: http://groups.google.com/group/django-developers/browse_thread/thread/3d4039161f6d2f5e/ I really like Honza's idea of an AggregateModel, at least for cases where there's a 1-1 correspondence between results and actual instances, so that the model will still behave as expected. To keep from cluttering the model's attributes, aggregate values could be put into another object or dict: >>>myproduct.aggregates['avg_price'] I like the idea less when the result would be a representative of a group. There could be unexpected results from calling methods on an instance because not all the data is there, or it has invalid values (averaging an integer field, etc). In these cases, I don't think it's a bad idea to require the use of values() and/or aggregate(). Also, there will probably be cases where we'd want to iterate over the members of the groups, so maybe instead of a list of dicts, aggregate() returns list of objects, so that a query like: >>> people = Person.objects.values('age').aggregate(Avg('income')) will return a list of objects that you can use like a dict: >>>people[0]['age'] and get a queryset from: >>>people[0].objects() On Sun, Apr 27, 2008 at 11:26 AM, Nicolas Lara <[EMAIL PROTECTED]> wrote: > Having multiple classes seems confusing. > I'm not sure why multiple classes would be confusing, since they do represent different behaviors. If it has to do with dealing with many classes, then it doesn't seem different than the many function names that need to be passed to the A class. > I would propose to have a single class (A?) to do the queries. So you > could do something like: > > aggregate(height=A('max', 'height'), av_friend_age=A('avg', > 'friend__age')) > At least for readability, I think this is clearer: aggregate(height=Max('height'), av_friend_age=Avg('friend__age')) In addition, some cases have special requirements and dealing with them in a class is easy. Cheers, Justin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
