>
> > Talking through my hat?No, I think not -- I think that syntax
> > (``queryset.groupby(field).max()``)
> actually looks like the best proposal for aggregates I've seen thus far...
>
Sounds pretty good to me. Besides the usual min, max and such, I also
like:
queryset.groupby(field).stats()
On 12/4/06 5:57 AM, John Lenton wrote:
> 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 tu
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"
On 12/2/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> But isn't it also dangerous to code (or not code) for future cases that
> may or may never come? If a non-relational database backend isn't
> anywhere on the current horizon, why not code aggregates and groups to
> the current usage and break
On 12/1/06 11:40 AM, Rob Hudson wrote:
>> 4 - If you search the archives (user and developer), you will find several
>> discussions on aggregate functions. group_by() and having() (or
>> pre-magic-removal analogs thereof) have been rejected previously on the
>> grounds that the Django ORM is not i
Thanks for the reply, Russell. It's obviously a lot more complex and
detailed than simply adding a min() where count() is. :)
A couple thoughts...
> 4 - If you search the archives (user and developer), you will find several
> discussions on aggregate functions. group_by() and having() (or
> pr
I'd like to see this type of support in the main branch, not separated.
It seems that better support for floating point is just a deficiency in
Django today and the aggregation need crops up everywhere - not just in
scientific applications.
My needs for aggregation are simply for reporting: e.g.
Yeah it is all coming back to me. I was unwilling to answer all of
these questions and create the perfect solution (which may not exist)
and therefore we don't have aggregates in Django even though I
demonstrated that a straightforward implementation was possible way
back when. Thanks for backing
On 11/30/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
>
> I think for those who need aggregate data these would cover a lot of
> ground. I'd be willing to work on a patch if this is considered
> generally useful and we can work out what the API should look like.
>
>
1 - I'm agreed on the need for e
On Nov 29, 2:30 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> > I needed aggregates. (I also learned about data bubbles and redesigned
> > my tables to include them as necessary. This redesign eliminated almost
> > all of my needs for an aggregate function interface.)Whatsa data bubble?
> >
> I needed aggregates. (I also learned about data bubbles and redesigned
> my tables to include them as necessary. This redesign eliminated almost
> all of my needs for an aggregate function interface.)
Whatsa data bubble? Google and Wikipedia don't seem to know...
--~--~-~--~~-
I created such a patch last spring during the Django sprint at PyCon.
The basic interface was very straightforward but there was also a
slightly less straightforward interface option that allowed for
grouping and so forth. The patch was discarded, however, since some of
the core Django developers
12 matches
Mail list logo
