Hi Justin,
> 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().
>
I didn't understand your point here. When is the data incomplete? and
I dont see the problem in averaging an integerField (probably in
averaging a CharField, but IMHO this kind of invalid values should
make the whole query fail).
> 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'))
>
> and get a queryset from:
>
> >>>people[0].objects()
>
I like this idea quite a lot. It is basically a shortcut for a common
use case that is generating a QuerySet for the objects that have been
aggregated.Still, doing this queryset manually is also very simple.
> 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'))
I aggre. An advantage (which I think might also be a double edge
sword) of the string function names is the possibility to fallback to
a standard convertion to SQL when no function is defined. With this we
wouldn't need to wrap every aggregate method in a python class that
translates roughly the same way and we could take advantage of the
direct usage of the DB defined aggregate functions. Also with the A
syntax you would do only one import instead of one for each function.
Still the point of readability is a very important one and I believe
it might come before other features.
> In addition, some cases have special requirements and dealing with them in a
> class is easy.
>
I can't think of a requirement that can't be dealt with in a method
also... got an example?
Regards,
Nicolas
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
