#25811: Error querying models in different databases in one queryset
-------------------------------------+-------------------------------------
Reporter: ebar0n | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: database | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by shaib):
Replying to [comment:10 ebar0n]:
> It would also be necessary to specify that functionality in the
documentation {{{__IN}}}
> , that would be the only exception to not generate the subquery.
You seem to be missing @jarshwah 's main concern: Your fix is all nice and
well when the subquery returns a small number of records. But assume it
can return thousands of records -- even if the external query returns only
a few in the end. Say "find customers with last name Baron who made a
purchase", written as
{{{
Customer.objects.filter(last_name='Baron',
customer_id__in=
Purchase.objects.all().values_list('customer_id'))
}}}
(I know this doesn't look realistic, it is simplified for the sake of
example, but believe me, there are plenty of such queries).
Now, as long as we're all in one database, this may well be efficient
enough, because only the small number of records will finally be returned,
and the database can usually make sure to execute such a query efficiently
internally.
But with your fix, and if `Purchase` is on a different database, this
query suddenly becomes a performance disaster. Further, there is no way
for Django to tell if the inner query is "fast enough".
This is why Josh prefers that the fix will be, instead of "just go and get
it", to make the error informative and tell the developer how to fix it.
For what it's worth, I agree.
Josh, is it possible for a user to override the built-in lookups?
@ebar0n's concern seems to be that there are a lot of queries in his code-
base which would need to be changed if we don't fix it as he suggests,
and where performance is probably not an issue. If he can just override
`__in` with a lookup that does what he wants, then we can have our cake
and he can eat it too.
--
Ticket URL: <https://code.djangoproject.com/ticket/25811#comment:12>
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.d65312bb03a26421a4d82938f9fb2cb1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
