#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 , 17 years ago
Attachment: | sample-fix.txt added |
---|
comment:1 by , 17 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 , 17 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 17 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