ey would be good
> additions to Django. From a purely idea point of view, this is all
> win.
>
> What is missing from this proposal is any indication that you have
> given any thought to these problems beyond "Hey, that ticket looks
> cool". Have you made estimates of h
ting in the Google SoC event this year?
> >
> > We'll be applying, yes.
>
> Did Django apply for GSoC 2009(seems like Google is already accepting
> Org Applications
> till 13th this month)? If so can some one kindly link me to the Ideas
> page?
>
> >
>
-
>
> Lastly - some thank-yous. This commit wouldn't have been possible
> without the assistance of many other people.
>
> Nicolas Lara did some excellent work turning a specification into a
> working implementation as part of the 2008 Google Summer of Code.
> Nicolas - take
egates (and
columns selected via extra() ) working with F objects.
All that's left now is a bit of community testing. I'll keep the
patches updated and be aware of any bug that might arise to try and
fix it as soon as possible.
Best Regards =),
--
Nicolas Lara
--~--~-~--~
ary seams like an easy fix
>> that
>> I might do while working on aggregates but I'd like to know the
>> feeling
>> of the comunity on this.
>
> Patches welcome, and please file a ticket so this bug is not forgotten.
>
> Thanks,
> Gary
>
> >
>
--
>
> My point is that the user shouldn't ever need to worry. A list that
> contains multiple versions of similar things is easy to process by
> iteration. A list that contains "similar things except for the one the
> isn't" is not as trivial to process.
>
>
> Bleh. Adding methods to clean up after
On Mon, Jun 2, 2008 at 8:53 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Sun, Jun 1, 2008 at 9:04 PM, Nicolas Lara <[EMAIL PROTECTED]> wrote:
>>
>> I dont mind changing it to indexes. To me it is more readable with the
>> list copying/slicing. I
to be an issue.
So far I like the idea of using something like:
values('field','field', groups='group_name')
So the user can pick the name of the grouping. This way we allow to
have more meaningful names for the list of objects. For example:
Book.objects.all().values(
>
> Providing a way to count different fields is a good idea, and the
> approach you've described looks good to me. I just wanted to make sure
> that the simplest case (count all instances) is trivial (i.e., doesn't
> require explicit naming of the PK field).
>
This is fixed in the latest revisio
Hi Karen,
On Mon, May 26, 2008 at 7:24 PM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> (The other aggregate thread has gotten a bit long and hard to find things in
> so I've started a new thread for this question.)
>
no prob, =)
> Moving on to another of my crossword DB stats pages, what I displa
n a
> neat admin UI to the user :(
>
> Please do let me know of any suggestions/criticisms and/or feedback.
>
> --
> Cheers
> Thejaswi Puthraya
> http://thejaswi.info/
> >
>
--
Nicolas Lara
Linux user #380134
Public key id: 0x152e7713 at http://keyserver.nore
age' in the dictionary.
I was wondering if there was some sort of design decision on this or
was just not implemented (yet). Adding the fields to appear in the
dictionary seams like an easy fix that I might do while working on
aggregates but I'd like to know the feeling of the comunit
I've been thinking about this issue, so here are some thoughts:
I like Jeff's idea on inserting the results into the template. I agree
also that the errors in-place pose problems since, as Simon commented,
the errors would not be visible in some cases.
Also the fail silently feature _can_ be _ve
> I ran the tests that come with django trunk and
> there are 4 failures, is this known?
>
Actually 5:
4 in regressiontests.defaultfilters.tests and 1 in
regressiontests.templates.tests...
I was about to post the same thing.
Regards,
Nicolas
--~--~-~--~~~---~--~--
te would replace GROUP BY, and should
> > > also be able to replace distinct().
> >
> > Why would replacing distinct() ever make any sense?
> >
> > --
> > Collin Grady
> >
> >
> >
>
>
>
> --
> David Cramer
> Director
>
> > Annotate returns a query set of objects, but with each returned object
> > enhanced with aggregated attribute(s) (e.g., a list of people, each of
> > which is annotated with the sum of their individual purchases)
> >
> > Aggregate returns the summary s
interesting?"
>>
>> The goal is not necessarily to enable _every_ aggregate query to be
>> expressed using the Django ORM, but we do want the most common queries
>> to be expressed easily. If your examples are extraordinarily complex,
>> they may be outside the
t be found under tests/modeltests/
>> > aggregation/ of the current state of the project. They can probably do
>> > as documentaion in the early stages of the project (i.e. now :p )
>>
>> > Any comments or sugestions are more than welcome! :-)
>>
>> > Nico
. Some tests might be found under tests/modeltests/
>> aggregation/ of the current state of the project. They can probably do
>> as documentaion in the early stages of the project (i.e. now :p )
>>
>> Any comments or sugestions are more than welcome! :-)
>>
>> N
one for the annotation and this:
> >
> >SELECT MAX("t_buyer"."age") FROM "t_buyer"
> >
> > for aggregating on the whole model.
> >
> > With (1) we can get unexpected results. Imagine we were not usi
;for aggregating on the whole model.
> >
> > 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.
> > With (2) we would have to make 2 queries while t
ic functions, but like extras, it should
> probably
> > > be clearly advanced functionality.
> >
> > I am not sure either. I see the problems it might bring.
> >
> >
> >
> > > Ideally expressions.py should be import * friendly
> >
> >
with in a method
> > also... got an example?
> >
>
>
> Count() is an easy example. First, it takes an extra kwarg, 'distinct', and
> changes the output of as_sql() if set. Then it also has to do a special case
> in relabel_aliases() and whatever method passes column na
eturn 'CUSTOM(%s)' % column
class WierdMax(Max):
def as_sql(self, column):
return super(Max, self).as_sql(column) - 10
so
aggregate(A('custom', 'height'), wierd=A('wierdmax', 'friend__age'))
would result in somethin
rovide certain
> pieces of functionality -- in this case, aggregations support -- that is
> mapped to SQL. So the SQL will use "having" and "group by" but they
> don't to be exposed at the Python level.
>
> Regards,
> Malcolm
>
> --
>
25 matches
Mail list logo
