#36648: "pk" exception from guard against using first() on unordered queryset with
aggregation does not consider composite pk fields provided separately
-------------------------------------+-------------------------------------
Reporter: Jacob Walls | Type: Bug
Status: new | Component: Database
| layer (models, ORM)
Version: 5.2 | Severity: Release
| blocker
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Discovered while poking into the source for `first()` that we have a
special case for `"pk"` that does not behave equivalently for composite
primary key fields specified individually.
A test for `CompositePKAggregateTests`:
The commented out assertion shows the point of the guard -- it should
raise a TypeError in most cases of using first() on an unordered queryset,
see #33772.
The second assertion shows the exception for `values("pk")` -- this does
not raise.
The third assertion tries to provide the values for a composite pk
separately -- this should not raise...
{{{#!py
def test_group_by_guard(self):
# This assertion passes, only included to demonstrate the
behavior.
# with self.assertRaises(TypeError):
#
Comment.objects.values("text").annotate(max=Max("id")).first()
Comment.objects.values("pk").annotate(max=Max("id")).first() #
passes
Comment.objects.values("tenant",
"id").annotate(max=Max("id")).first() # fails
}}}
... but does:
{{{#!py
TypeError: Cannot use QuerySet.first() on an unordered queryset performing
aggregation. Add an ordering with order_by().
}}}
--
Ticket URL: <
https://code.djangoproject.com/ticket/36648>
Django <
https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.