Opened 13 years ago
Closed 13 years ago
#16688 closed Bug (duplicate)
unionagg doesn't respect limits
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | GIS | Version: | 1.3 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
When specifying a limit with slice syntax and then running unionagg, this limit is not taken into account. In the below example, unionagg is run on the entire set of records rather than only 10 records as expected:
qs = Model.objects.all()[:10] ua = qs.unionagg()
Change History (2)
comment:1 by , 13 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 13 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
Duplicate of #15101 (Extent aggregate instead).
Note:
See TracTickets
for help on using tickets.
Slicing a QuerySet basically tacks "LIMIT foo" at the end of the generated SQL. As a consequence, the slicing applies after the aggregation.
The same problem is handled properly in the case of
filter:MyModel.objects.filter(...)[:10].filter(...)raisesAssertionError: Cannot filter a query once a slice has been taken.I think aggregating a query after a slice has been taken should also raise an
AssertionError.