This is a bleeding-edge feature that I'm currently skewered upon and quickly bleeding out. I want to annotate a subquery-aggregate onto an existing queryset. Doing this before 1.11 either meant custom SQL or hammering the database. Here's the documentation for this, and the example from it:
from django.db.models import OuterRef, Subquery, Sum
comments = Comment.objects.filter(post=OuterRef('pk')).values('post')
total_comments = comments.annotate(total=Sum('length')).values('total')
Post.objects.filter(length__gt=Subquery(total_comments))
They're annotating on the aggregate, which seems weird to me, but whatever.
I'm struggling with this so I'm boiling it right back to the simplest real-world example I have data for. I have Carpark
s which contain many Space
s. Use Book→Author
if that makes you happier but —for now— I just want to annotate on a count of the related model using Subquery
*.
spaces = Space.objects.filter(carpark=OuterRef('pk')).values('carpark')
count_spaces = spaces.annotate(c=Count('*')).values('c')
Carpark.objects.annotate(space_count=Subquery(count_spaces))
This gives me a lovely ProgrammingError: more than one row returned by a subquery used as an expression
and in my head, this error makes perfect sense. The subquery is returning a list of spaces with the annotated-on total.
The example suggested that some sort of magic would happen and I'd end up with a number I could use. But that's not happening here? How do I annotate on aggregate Subquery data?
Hmm, something's being added to my query's SQL...
I built a new Carpark/Space model and it worked. So the next step is working out what's poisoning my SQL. On Laurent's advice, I took a look at the SQL and tried to make it more like the version they posted in their answer. And this is where I found the real problem:
SELECT "bookings_carpark".*, (SELECT COUNT(U0."id") AS "c"
FROM "bookings_space" U0
WHERE U0."carpark_id" = ("bookings_carpark"."id")
GROUP BY U0."carpark_id", U0."space"
)
AS "space_count" FROM "bookings_carpark";
I've highlighted it but it's that subquery's GROUP BY ... U0."space"
. It's retuning both for some reason. Investigations continue.
Edit 2: Okay, just looking at the subquery SQL I can see that second group by coming through ☹
In [12]: print(Space.objects_standard.filter().values('carpark').annotate(c=Count('*')).values('c').query)
SELECT COUNT(*) AS "c" FROM "bookings_space" GROUP BY "bookings_space"."carpark_id", "bookings_space"."space" ORDER BY "bookings_space"."carpark_id" ASC, "bookings_space"."space" ASC
Edit 3: Okay! Both these models have sort orders. These are being carried through to the subquery. It's these orders that are bloating out my query and breaking it.
I guess this might be a bug in Django but short of removing the Meta-order_by on both these models, is there any way I can unsort a query at querytime?
*I know I could just annotate a Count for this example. My real purpose for using this is a much more complex filter-count but I can't even get this working.
A solution which would work for any general aggregation could be implemented using
Window
classes from Django 2.0. I have added this to the Django tracker ticket as well.This allows the aggregation of annotated values by calculating the aggregate over partitions based on the outer query model (in the GROUP BY clause), then annotating that data to every row in the subquery queryset. The subquery can then use the aggregated data from the first row returned and ignore the other rows.
I just bumped into a VERY similar case, where I had to get seat reservations for events where the reservation status is not cancelled. After trying to figure the problem out for hours, here's what I've seen as the root cause of the problem:
Preface: this is MariaDB, Django 1.11.
When you annotate a query, it gets a
GROUP BY
clause with the fields you select (basically what's in yourvalues()
query selection). After investigating with the MariaDB command line tool why I'm gettingNULL
s orNone
s on the query results, I've came to the conclusion that theGROUP BY
clause will cause theCOUNT()
to returnNULL
s.Then, I started diving into the
QuerySet
interface to see how can I manually, forcibly remove theGROUP BY
from the DB queries, and came up with the following code:So basically, you have to manually remove/update the
group_by
field on the subquery's queryset in order for it to not have aGROUP BY
appended on it on execution time. Also, you'll have to specify what output field the subquery will have, as it seems that Django fails to recognize it automatically, and raises exceptions on the first evaluation of the queryset. Interestingly, the second evaluation succeeds without it.I believe this is a Django bug, or an inefficiency in subqueries. I'll create a bug report about it.
Edit: the bug report is here.
"works for me" doesn't help very much. But. I tried your example on some models I had handy (the
Book -> Author
type), it works fine for me in django 1.11b1.Are you sure you're running this in the right version of Django? Is this the actual code you're running? Are you actually testing this not on
carpark
but some more complex model?Maybe try to
print(thequery.query)
to see what SQL it's trying to run in the database. Below is what I got with my models (edited to fit your question):Not really an answer, but hopefully it helps.
If I understand correctly, you are trying to count
Space
s available in aCarpark
. Subquery seems overkill for this, the good old annotate alone should do the trick:This will include a
spaces__count
value in your results.OK, I have seen your note...
I was also able to run your same query with other models I had at hand. The results are the same, so the query in your example seems to be OK (tested with Django 1.11b1):
Maybe your "simplest real-world example" is too simple... can you share the models or other information?
Shazaam! Per my edits, an additional column was being output from my subquery. This was to facilitate ordering (which just isn't required in a COUNT).
I just needed to remove the prescribed meta-order from the model. You can do this by just adding an empty
.order_by()
to the subquery. In my code terms that meant:And that works. Superbly. So annoying.
It's also possible to create a subclass of
Subquery
, that changes the SQL it outputs. For instance, you can use:You then use this as you would the original
Subquery
class:You can use this trick (at least in postgres) with a range of aggregating functions: I often use it to build up an array of values, or sum them.