#28765 closed Cleanup/optimization (fixed)
Clarify the documentation about what types the __in lookup accepts
Reported by: | Дилян Палаузов | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | 1.11 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Clarify, that [two underscores]in accepts any iterable (e.g. dict.keys())
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -2520,7 +2520,7 @@ SQL equivalent:: ``in`` ~~~~~~ -In a given list. +In a given iterable. Example::
Change History (7)
comment:1 by , 7 years ago
Component: | Database layer (models, ORM) → Documentation |
---|---|
Summary: | Documentation __In lookup → Clarify the documentation about what types the __in lookup accepts |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 7 years ago
String is accepted, at least with Postgresql. E.g. when a column consists of a single letter x = models.Char(max_char=1, default='A')
then ...objects.filter(x__in='ABC')
is valid.
comment:3 by , 7 years ago
You're correct, but that generates WHERE x IN (A, B, C)
which I don't think is intuitive.
comment:4 by , 7 years ago
The SQL generated is correct for the case. I find it also intuitive, as this is also what I would have expected.
Back to he original question: are there any reason against clarifying that the _in lookup accepts iterables of any kind, not just lists?
I'm not sure if "iterable" is the best term. For example, a string is iterable but isn't accepted.