Opened 3 weeks ago
Last modified 10 days ago
#37430 assigned Cleanup/optimization
Make database selection for subqueries consistent and document its behavior
| Reported by: | Lev Zlobin | Owned by: | Lev Zlobin |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | documentation queryset multiple-databases subquery routing |
| Cc: | Simon Charette | Triage Stage: | Accepted |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
- Without an explicitly selected database, the subquery uses the outer query's connection rather than being routed independently.
- Explicitly selecting a different database for the inner queryset raises
ValueError. - Evaluating the inner queryset with
list()allows values to be retrieved from another database.
Add examples to the multiple-databases guide and cross-references from the using() and in lookup documentation.
This documentation improvement was split out from https://code.djangoproject.com/ticket/37427 following review on github https://github.com/django/django/pull/22154.
Change History (1)
comment:1 by , 10 days ago
| Cc: | added |
|---|---|
| Component: | Documentation → Database layer (models, ORM) |
| Easy pickings: | unset |
| Summary: | Clarify database selection when a queryset is used in an {{{__in}}} lookup: → Make database selection for subqueries consistent and document its behavior |
| Triage Stage: | Unreviewed → Accepted |
Note:
See TracTickets
for help on using tickets.
From what I can see, the outer query’s database connection is also used for
Subquery()andExists()but unlike theinlookup, these silently ignore an explicit database selection on the inner queryset. See below:tests/multiple_database/tests.py
signalsPerhaps we should document the general database-selection rule in the multiple-databases guide, with cross-references from
in,Subquery(), andExists().It might also be worth considering whether conflicting explicit database selections should consistently raise an error like what was introduced in #25811