On 12/1/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> One way to think about the problem is to consider how you would write
> the documentation for it. "Django implements an object based SQL
> wrapper... except for the aggregations stuff, which you will need to
> know SQL to use properly". If the documentation sounds like it will be
> ugly, so is the implementation :-)
>
> So; lots to think about, but don't let that discourage you. As this
> thread has shown, there is plenty of interest in having aggregates -
> the discussion will probably be long, but if we can get something
> productive out of it, Django will be all the better for it.
Me myself, I think that the "group by" functionality isn't a problem;
if you look at how itertools.groupby works, it would be both easy and
natural (ie pythonic) to give querysets a groupby function with
similar semantics and laziness.
The "max", "min" and other such functions might be a little more
problematic, unless groupby returned, rather than a generic iterator,
a special "queryset group" and give _it_ the max/min/etc methods. This
way it would be clear that max() returns a tuple (value, queryset) (to
me, at least...). Also, ...groupby('foo').max() would return the same
result as max(...groupby('foo')), but less efficiently.
Talking through my hat?
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
The trouble with a lot of self-made men is that they worship their creator.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
