#14030: Use F() objects in aggregates(), annotates() and values()
---------------------------------+------------------------------------
Reporter: delfick | Owner: nate_b
Type: New feature | Status: assigned
Component: ORM aggregation | Version:
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
---------------------------------+------------------------------------
Changes (by akaariai):
* needs_better_patch: 0 => 1
* version: 1.2 =>
Comment:
I am wondering about the hack in the patch: that is, adding an empty
Aggregate over the given F expression. I guess the reason is to make this
work:
{{{
>>> q =
Entry.objects.annotate(cpb_ratio=F('n_comments')*1.0/F('n_pingbacks'))
}}}
Now, I have been wondering about something similar. In fact, I have been
thinking of creating expressions you can inject into the query by
.annotate().
{{{
caseexpr = RawSQL("case when %s > 0 then 'has '||%s||' comments' else 'no
comments' end",
params=(F('n_comments'), F('n_comments')))
}}}
And you could then do
{{{
>>> q =
Entry.objects.annotate(has_comments=caseexpr).order_by('has_comments')
(or, in my dreams the .order_by parameter could be .order_by(RawSQL('%s
asc nulls last', params=(F('has_comments'),))
}}}
In effect, you could get rid of most .extra() uses by the above
annotations. I have some reason to believe that the above changes, if
implemented correctly, would make the ORM both faster and easier to
understand. Of course, without an actual patch it is easy to claim that...
:)
Now, my point here is that I really like the ability to use annotations
for other expressions than aggregates. But I really, really do not like
the idea of adding an empty aggregate that in fact is not an aggregate. I
bet that will break under some complex query, because Django thinks you
have an aggregate in the query, but in SQL you do not have one. So, +1 on
the idea, -1 on the current implementation.
BTW: I am clearing the version field, from the documentation it seems the
version field "Finally, it is possible to use the version attribute to
indicate in which version the reported bug was identified.". Now, I read
that as if there is no bug, there should not be any version either.
Learning this as I write, so please correct if I am wrong.
--
Ticket URL: <https://code.djangoproject.com/ticket/14030#comment:15>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" 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-updates?hl=en.
