#34125 closed Bug (fixed)
Limiting QuerySet crashes on union() with a single non-empty query
Reported by: | Stefan Hammer | Owned by: | Simon Charette |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Release blocker | Keywords: | |
Cc: | bcail, Simon Charette | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
We have an union-query, that works up until django 4.1.2, but stopped working with the latest dev-version of django.
Basically, one QuerySet is non-empty, and the other one is empty, simplified:
q1 = PageLogEntry.objects.all().order_by() q2 = q1.union(PageLogEntry.objects.none()) q2.order_by()[:1]
With PostgreSQL this leads to the following SQL (I've reduced the SQL to one field only -> "..."):
(SELECT "wagtailcore_pagelogentry"."id", ... FROM "wagtailcore_pagelogentry" LIMIT 1) LIMIT 1;
which results in this error:
psycopg2.errors.SyntaxError: multiple LIMIT clauses not allowed LINE 1: ..."."page_id" FROM "wagtailcore_pagelogentry" LIMIT 1) LIMIT 1
With django 4.1.2 the following valid SQL is generated:
(SELECT "wagtailcore_pagelogentry"."id", ... FROM "wagtailcore_pagelogentry") LIMIT 1;
With sqlite no errors are thrown in the dev-version.
Note: In our actual queries, we use ordering (we remove ordering in the inner queries with order_by()
and apply an ordering to the resulting union-queryset), but that does not change anything, since the limit seems to be the issue, so I've removed ordering to minimize the SQL.
I've found a similar, fixed bug #32116, but in that case order_by had an issue.
Attachments (1)
Change History (9)
comment:1 by , 2 years ago
Cc: | added |
---|
comment:2 by , 2 years ago
Summary: | Limitting QuerySet crashes on union() with a single non-empty query → Limiting QuerySet crashes on union() with a single non-empty query |
---|
comment:3 by , 2 years ago
Cc: | added |
---|---|
Severity: | Normal → Release blocker |
Triage Stage: | Unreviewed → Accepted |
Thanks for the report! I attached a regression test which generates the following SQL on PostgreSQL:
(SELECT "queries_number"."id", "queries_number"."num", "queries_number"."other_num", "queries_number"."another_num" FROM "queries_number" WHERE "queries_number"."num" <= 0 LIMIT 1) LIMIT 1;
Regression in 3d734c09ff0138441dfe0a59010435871d17950f.
Reproduced at de2c2127b66e77a034c01c81753c5c08e651a5b4.
comment:4 by , 2 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 2 years ago
Has patch: | set |
---|
comment:6 by , 2 years ago
The patch in its current form should address the reported issue and also cover other use cases that were not covered when dealing with slicing combined queries that are sliced themselves.
Using the following diff:
git bisect says that 3d734c09ff0138441dfe0a59010435871d17950f is the first bad commit.