"pk" exception when using first() on unordered queryset with aggregation does not consider composite pk fields provided separately
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...
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:
TypeError: Cannot use QuerySet.first() on an unordered queryset performing aggregation. Add an ordering with order_by().
Change History
(11)
| Keywords: |
compositepk added
|
| Triage Stage: |
Unreviewed → Accepted
|
| Summary: |
"pk" exception from guard against using first() on unordered queryset with aggregation does not consider composite pk fields provided separately → "pk" exception when using first() on unordered queryset with aggregation does not consider composite pk fields provided separately
|
| Owner: |
set to Jacob Walls
|
| Status: |
new → assigned
|
| Triage Stage: |
Accepted → Ready for checkin
|
| Resolution: |
→ fixed
|
| Status: |
assigned → closed
|
PR