This topic is discussed on the Ticket #11305 :
https://code.djangoproject.com/ticket/11305
Like many folks, I am hit by the scenario where a relative simple
query become a design decision because my «boss» asked me : "Hey Stan,
can you add me a column with the number of valid items in each
category ?".
Here we have two bad solutions :
1. Move the nice orm-ed query in a db-dependant, pain-in-the-arse-
to[write|maintain] raw sql one ;
2. Write a MonkeyCount() that take some arbitrary sql code with
hardcoded tablename.
I have picked the second one but I am not really happy with it. I am
in a early stage and I don't want to have a surprise of a database
incompatible patch when I will deploy.
And being lazy I also don't want to build a pre-production server
right now just to test that.
Ok, I know I am lazy and this solution is just fine. But a lot of
people lose a small amount of time because of this gap.
As Russellm said 2 years ago : "the Django core should be exposing the
tools that make it possible for end-users to write their own complex
aggregates".
But I do not fully agree with this request beeing specific.
Maybe we could implement something that cover all the aggregate
functions and all conditional cases ?
In terms of design, is something like that absolutely stupid ? :
Aggregate(lookup, only=None, **kwargs)
By example:
queryset.aggregate(
expensive_house=Count(house__price,
only=(Q(house__price__gt=41000), Q(house__price__lt=43000))),
...
)
At first sight, this is not a negligible amount of time of devel but I
think it worth the shot !
Thanks in advance.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
