#17459: Subquery fails across multiple databases
-------------------------------------+-------------------------------------
Reporter: dgouldin | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 1.3
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by lrekucki):
* status: new => closed
* needs_docs: => 0
* resolution: => wontfix
* needs_tests: => 0
* needs_better_patch: => 0
Comment:
After thinking about this for a while, I think it's not something Django
should do implicitly.
First of all, because this results in some serious performance drawback
that's hidden in a place you normally wouldn't expect it to be and it
gives a false impression of us supporting cross-database queries (which we
don't).
Second, because it's not always the right thing to do. Taking the (naive)
example of master-slave configuration from the docs, the fact that the
router returns different slaves for Bar and Foo, shouldn't prevent Django
from generating the subquery. As Django has no other way of knowing, which
dbs contain which tables, we can't assume that the table is or isn't
there.
Explicitly using {{{list()}}} fixes the problem and is more explicit about
performance/memory overhead of the query.
--
Ticket URL: <https://code.djangoproject.com/ticket/17459#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
