On Thu, May 1, 2008 at 10:07 PM, Nicolas E. Lara G.
<[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> With (1) we can get unexpected results. Imagine we were not using max
> but sum instead, the buyer's age would be sumed as many times as he
> has made a purchase.
I disagree that (1) is unexpected -
Also I believe group by shouldn't happen on every column unless explicit. By
default it should group on primary key.
-Original Message-
From: Yuri Baburov <[EMAIL PROTECTED]>
Sent: Thursday, May 01, 2008 1:53 PM
To: django-developers@googlegroups.com
Subject: Re: Aggregate S
<[EMAIL PROTECTED]>
Sent: Friday, May 02, 2008 10:12 AM
To: django-developers@googlegroups.com
Subject: Re: Aggregate Support to the ORM
I am not sure I agree with you on this. Since the succesive calls to
aggregate/annotate would actually be constructing the elements for the
final query
I am not sure I agree with you on this. Since the succesive calls to
aggregate/annotate would actually be constructing the elements for the
final query in non ordered datastructures I think the order in which
different elements are inserted to the aggregation should not matter.
The values
> It's probably
> not a good idea to assume either point of view.
I agree
> I wonder if aggregate functions on the quesyset's model should even be
> allowed in annotate(). I can't think of a case that makes sense. That
> restriction would certainly get rid of some ambiguity.
This is a
can this be considered as difference of complex apply against 2
consequent applications of annotate?
like 2 filter applied one-by-one can be different from one complex filter?
like: .annotate('purchases__quantity__sum').annotate('age__max')
and .annotate('purchases__quantity__sum', 'age__max')?
Interesting problem. The real question is, what is the user's intent on a
query like that?
I have no idea. They probably are thinking along the lines of result #2 if
they don't understand the underlying SQL and #1 if they do. It's probably
not a good idea to assume either point of view. Using Sum
Hello,
I've been looking into the different use cases for aggregation and
came across one that I wasn't very sure what should be the expected
behaviour (regardless of the syntax used to express it)
If we do something like:
Buyer.objects.all().annotate('purchases__quantity__sum', 'age__max')
On Tue, Apr 29, 2008 at 1:25 AM, Justin Fagnani
<[EMAIL PROTECTED]> wrote:
>
>
> On Mon, Apr 28, 2008 at 2:10 PM, Nicolas E. Lara G. <[EMAIL PROTECTED]>
> wrote:
> > I didn't understand your point here. When is the data incomplete?
>
> An example would be grouping people by age and averaging
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
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
> That was my thinking exactly. I think the cognitive dissonance
> involved in height__avg='average_height' is much greater than that in
> ({'average_height': 'height__avg}). Sure, it's new ORM syntax but it's
> also a new ORM feature. Overloading the existing syntax to do
> something that's
On Apr 27, 1:59 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Its mostly there as a convenience for the really simple cases. There
> some duplication in typing annotate(avg_height=Avg('height'), so the
> shortcut is a convenience. IMHO, this is the sort of thing could be
> easily
I like the lookup objects idea for aggregates, it's similar to Q
objects and I think it works well. It is far more extensible then the
__ notation.
On Apr 26, 7:59 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Sun, Apr 27, 2008 at 6:32 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
On Sun, Apr 27, 2008 at 6:32 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Apr 26, 12:33 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
>
> > If the aggregate function is provided as an anonymous argument (e.g.,
> > Avg('height')), then the aggregate is asked to provide an
On Apr 26, 12:33 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> So - here's a slightly modified proposal. Last time this topic came up
> on django-dev, Justin Fagnani made an interesting suggestion which I
> think will answer your objections, and leaves open some interesting
>
On Sat, Apr 26, 2008 at 6:32 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Apr 26, 7:34 am, "Ian Kelly" <[EMAIL PROTECTED]> wrote:
> > On Fri, Apr 25, 2008 at 11:40 PM, Russell Keith-Magee
> >
>
> > <[EMAIL PROTECTED]> wrote:
> > > > Have you considered syntax that looks like this
On Apr 26, 7:34 am, "Ian Kelly" <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 25, 2008 at 11:40 PM, Russell Keith-Magee
>
> <[EMAIL PROTECTED]> wrote:
> > > Have you considered syntax that looks like this instead? :
> > > >>> Students.objects.all().aggregate({'average_height': 'height__avg})
> >
On Fri, Apr 25, 2008 at 11:40 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> > Have you considered syntax that looks like this instead? :
> > >>> Students.objects.all().aggregate({'average_height': 'height__avg})
> > > {'average_height' : 1.43}
>
> My issue with this syntax is that
On Fri, Apr 25, 2008 at 9:35 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Apr 22, 9:24 pm, "Nicolas E. Lara G." <[EMAIL PROTECTED]>
> wrote:
>
> > So a QuerySet might be:
> > >>> Students.objects.all().aggregate(height__avg='average_height')
> > {'average_height' : 1.43}
>
> This
I would love to see something like AggregateModel returned from
.values().annotate()
it would work like:
for m in Model.objects.values( 'name', 'place' ).annotate(
event__count='number_or_events' )
# the basic data would be available right away
print m['number_or_events'], m['place'],
On Thu, Apr 24, 2008 at 10:14 PM, Nicolas Lara <[EMAIL PROTECTED]> wrote:
> On the ıssue of returnıng model objects ınstead of values
> (dıctıonarıes): I belıeve the problem wıth that ıs ınconsıstency,
> sınce when usıng values to restrıct the elements that are grouped
> together you cannot
Sorry ıf thıs goes on the wrong thread. I am wrıttıng at the moment
from turkey, where google groups ıs blocked.
In short: I belıeve Malcom's reply says ıt all except for the fact
that the 'havıng' clause would be expressed wıth a fılter modıfıer.
The ORM would take care of puttıng the requested
On Wed, 2008-04-23 at 07:50 -0700, Eratothene wrote:
> It looks that API lacks support for SQL HAVING clause, this one should
> be distinct from filter, GROUP BY without HAVING is often useless.
>
> Consider adding it to api (something like
>
It looks that API lacks support for SQL HAVING clause, this one should
be distinct from filter, GROUP BY without HAVING is often useless.
Consider adding it to api (something like
Model.objects.aggregate(height__sum).having(sex='M'))
Also do not forget to add HAVING clause to .extra() method.
2008 at 1:54 AM, Nicolas E. Lara G.
>
> <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> > I have been selected to implement Aggregate support in the Django ORM
> > as a project for Google Summer of Code 2008 =) My mentor for this
> > project is Russell Keith-M
On Apr 22, 4:36 pm, Matthias Kestenholz <[EMAIL PROTECTED]> wrote:
> Hi.
>
> this is very exciting! I've one suggestion/question though.
>
> On Tue, 2008-04-22 at 13:24 -0700, Nicolas E. Lara G. wrote:
>
> > with the possibility of using non-keyword arguments for un-aliased
> > aggregation, in
> Regards
> Rajeev J Sebastian
>
> On Wed, Apr 23, 2008 at 1:54 AM, Nicolas E. Lara G.
>
> <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> > I have been selected to implement Aggregate support in the Django ORM
> > as a project for Google Summer of Code 2008 =
just as the builtin sum, avg, etc ?
Regards
Rajeev J Sebastian
On Wed, Apr 23, 2008 at 1:54 AM, Nicolas E. Lara G.
<[EMAIL PROTECTED]> wrote:
>
> Hello,
> I have been selected to implement Aggregate support in the Django ORM
> as a project for Google Summer of Code
Hi.
this is very exciting! I've one suggestion/question though.
On Tue, 2008-04-22 at 13:24 -0700, Nicolas E. Lara G. wrote:
> with the possibility of using non-keyword arguments for un-aliased
> aggregation, in which case the 'alias' would be automatically created
> from the query made:
> >>>
Hello,
I have been selected to implement Aggregate support in the Django ORM
as a project for Google Summer of Code 2008 =) My mentor for this
project is Russell Keith-Magee.
I am very happy with both being selected (of course :p) and, in
general, with all the projects that were selected
31 matches
Mail list logo
