#25260 closed Uncategorized (invalid)
Sets in "in" lookups should be converted to list if backend doesn't support sets
Reported by: | no | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.8 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Consider the following:
Model.objects.filter(pk__in = set([1, 1, 2, 3, 4, 3]))
If the backend is mysql, the generated SQL will contain WHERE id IN (1, 2, 3, 4)
. If the backend is postgresql there is an error: "can't adapt type 'set'".
Argument: switching between backends should not throw an error from the backend if the plain ORM (no backend-specific elements) is used.
I'm not sure where this belongs, but django shouldn't be throwing a backend error for this case.
Some potential fixes:
- Call
list()
on any iterable that's used for__in
filters. (Preferable for me, should be non-breaking except in edge-cases) - Disallow
set
s for all backends. (Enforces the same behaviour across all backends, but backward incompatible) - Add adapter for sets to postgresql backend. (Might cause strange behaviour in cases where the set is used for other contexts)
Attachments (1)
Change History (4)
by , 9 years ago
Attachment: | 25260-test.diff added |
---|
comment:1 by , 9 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 9 years ago
You're right. PEBKAC. The code that was throwing the error was an abstraction on top of using the raw cursor.execute
, which doesn't adapt sets for pgsql, I was under the impression the abstraction used the django ORM.
comment:3 by , 9 years ago
Resolution: | worksforme → invalid |
---|
I couldn't reproduce with the attached test case. Does it fail for you? Can you provide a failing test case?