#24141: contains() method for QuerySets
-------------------------------------+-------------------------------------
Reporter: gormster | Owner:
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by carljm):
You're right, but note that this is exactly parallel to the way
`QuerySet.count()` and `QuerySet.exists()` currently work - they use the
cache if it is populated, otherwise they execute a query. Of course,
there's no reason to ever call `QuerySet.count()` or `QuerySet.exists()`
multiple times in a loop, so maybe it will be more of a trap in this case.
But it's already true that if you do `.count()` on a queryset that you are
later populating fully, you've done an unnecessary extra query.
For your demonstration case, the cutoff between when it's more efficient
to do more queries vs more efficient to pull in the entire QuerySet is not
a priori clear; it would depend very much on the size of the whole
queryset and the number of objs you are checking for containment. Probably
for many such check-containment-of-multiple-objects cases the most
efficient approach will be to do a `values_list` query and check obj IDs
for membership in that set of IDs.
It's already true and will always be true, I think, that in order to
maximize query efficiency using the Django ORM, you have to understand how
it works. That includes things like knowing when to use `select_related`
and `prefetch_related`, and it also includes understanding the result
cache and what triggers populating it. In the end I don't think adding
`.contains(obj)` really changes much, it's just a nicer spelling for
`.filter(pk=obj.pk).exists()`. The question is really whether good use
cases for the latter are common enough to warrant adding a method. And I'm
really fine with either answer to that question, just didn't want the
feature request to be dismissed without good rationale.
--
Ticket URL: <https://code.djangoproject.com/ticket/24141#comment:6>
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/066.bbe71795394080540556268858e95a00%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
