#6956 closed (fixed)
Subqueries don't use custom queryset
| Reported by: | Ivan Illarionov | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | queryset-refactor |
| Severity: | Keywords: | ||
| Cc: | ivan.illarionov@… | Triage Stage: | Accepted |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
All classes in django/db/models/sql/subqueries.py subclass directly from Query class even if database backend has uses_custom_queryset feature. This makes as_sql() methods of these classes handle limits incorrectly with backends (eg oracle) that use different constructs.
Classes in django/db/models/sql/subqueries.py should sublass from backend-specific Query class the same way QuerySet class does.
Attachments (1)
Change History (5)
by , 18 years ago
| Attachment: | sample-fix.txt added |
|---|
comment:1 by , 18 years ago
Proposal: since all features used by custom QuerySet class were moved to Query class in qsrf branch it makes sense to rename uses_custom_queryset feature to uses_custom_query and make only the Query class customizable. QuerySet class could check for this feature and create its query attribute based on it.
comment:2 by , 18 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:3 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
(In [7426]) queryset-refactor: Querysets no longer need to be customised per-backend.
Instead, it's the Query class that is backend-dependent. So make that explicit
in the code (code should refer to sql.Query and they will always get the right
backend-specific class).
This also fixes the main part of #6956, in that the various subclasses of Query
automatically use any custom Query class.
Fixed #6956.
The fix extracted from external backend implementation