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
colas Lara <[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
fi
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 modifier
> 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 solution
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')?
co
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')
or
On Tue, Apr 29, 2008 at 12:49 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> Is it my understanding that aggregate would not return an actual
> object (from the original examples above).
>
> Also, in regards to HAVING support. Unless you plan to implement logic
> into .filter() which says "oh
Is it my understanding that aggregate would not return an actual
object (from the original examples above).
Also, in regards to HAVING support. Unless you plan to implement logic
into .filter() which says "oh hey this is from an aggregate, using
having" then this is a MUST. There's no other way y
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 incom
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 income, what should
the values of the name field be? None might make sense at first, as Honz
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 anoth
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
> 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 explaine
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 appro
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
> possibiliti
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 ins
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 ev
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 look
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 looks really great, but one thing that initially confused me was
the ordering of the arguments - it s
On Apr 22, 4:37 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
wrote:
> Hi Nicolas,
>
> First, congratulations on your GSOC selection :)
>
Thanks =)
> I would to know if you will be building some way to use PG custom
> aggregates. I have so far one custom aggregate and I wonder how it
> could wor
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 w
Looks like good stuff, the one thing that would be nice would be to
have annotate return Model Objects instead of dicts.
On Apr 22, 3:37 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
wrote:
> Hi Nicolas,
>
> First, congratulations on your GSOC selection :)
>
> I would to know if you will be buildi
27 matches
Mail list logo
