#30248 closed New feature (needsinfo)
Implement case insensitive fields in Sqlite — at Version 4
Reported by: | Stuart Axon | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | sqlite citext postgres |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Change History (4)
follow-up: 2 comment:1 by , 6 years ago
Component: | Uncategorized → Database layer (models, ORM) |
---|---|
Resolution: | → needsinfo |
Status: | new → closed |
Version: | 2.1 → master |
comment:2 by , 6 years ago
Replying to Carlton Gibson:
At that point I'm wondering if similar isn't supported across all four supported backends, in which case would we want to pull the fields out of
contrib
...?
If this is possible, it would then make sense to implement CharField(insensitive=True)
, with default of False
. Perhaps this could also work with TextField
?
comment:3 by , 6 years ago
Hey Nick.
If this is possible...
Oh, good idea.
If someone wants to tell me that this is on, happy to see this moved into the Accepted pile.
(Not sure what thoughts on a contrib.sqlite
would be if not... — probably leaning towards third-party I'd guess.)
comment:4 by , 6 years ago
Description: | modified (diff) |
---|
Cheers, I did send an initial mail to the dev list, but think it might have got eaten as I didn't see it (also had a bit of bad luck updating this ticket, updating the description, not leaving a comment).
One thing I found out, is that even with COLLATE NOCASE sqlites regexes don't default to case insensitive, so that would need some support at the django end.
I had a bit of a look into how the postgres citext works, but couldn't work out how to make Operators that integrate with Django in the same way.
I guess a really tiny implementation, as fields.py might be a start ?
Hi Stuart.
Short answer, "Yes, maybe". :)
First off would be proof-of-concept fields, maybe in a third-party (similar to exist for MySQL and Postgres already). The
CIText
fields are fairly minimal, so there may not be much here.Then an approach to the DevelopersMailingList to see if there were appetite to include such fields in Django itself. (At that point I'm wondering if similar isn't supported across all four supported backends, in which case would we want to pull the fields out of
contrib
...?) — The issue tracker isn't really the best place for that conversation.