diff options
| author | Malcolm Tredinnick <malcolm.tredinnick@gmail.com> | 2011-08-26 08:42:38 +0000 |
|---|---|---|
| committer | Malcolm Tredinnick <malcolm.tredinnick@gmail.com> | 2011-08-26 08:42:38 +0000 |
| commit | 4d2151196163f401c42da5adae4bb06f6adf3d71 (patch) | |
| tree | c579bd56331f48a13100b77e3807a43677e8547b /docs | |
| parent | c9da5db701096813e3a7b4c64a80f4ad42a8eef8 (diff) | |
Clarify the documentation around SQLite and case-sensitive string matching.
This was still causing some confusion, so I rewrote the section in the
database notes to encompass both substring matching and non-ASCII
case-insensitive equality checks, as well as putting in a stronger
callout on the "contains" filter.
Refs #16569.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16694 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/ref/databases.txt | 27 | ||||
| -rw-r--r-- | docs/ref/models/querysets.txt | 8 |
2 files changed, 26 insertions, 9 deletions
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index e1702f5a13..d9ea008521 100644 --- a/docs/ref/databases.txt +++ b/docs/ref/databases.txt @@ -380,14 +380,27 @@ specific to SQLite that you should be aware of. .. _sqlite-string-matching: -String matching for non-ASCII strings --------------------------------------- +Substring matching and case sensitivity +----------------------------------------- -SQLite doesn't support case-insensitive matching for non-ASCII strings. Some -possible workarounds for this are `documented at sqlite.org`_, but they are -not utilised by the default SQLite backend in Django. Therefore, if you are -using the ``iexact`` lookup type in your queryset filters, be aware that it -will not work as expected for non-ASCII strings. +For all SQLite versions, there is some slightly counter-intuitive behavior when +attempting to match some types of strings. These are triggered when using the +:lookup:`iexact` or :lookup:`contains` filters in Querysets. The behavior +splits into two cases: + +1. For substring matching, all matches are done case-insensitively. That is a +filter such as ``filter(name__contains="aa")`` will match a name of ``"Aabb"``. + +2. For strings containing characters outside the ASCII range, all exact string +matches are performed case-sensitively, even when the case-insensitive options +are passed into the query. So the :lookup:`iexact` filter will behave exactly +the same as the :lookup:`exact` filter in these cases. + +Some possible workarounds for this are `documented at sqlite.org`_, but they +aren't utilised by the default SQLite backend in Django, as incorporating them +would be fairly difficult to do robustly. Thus, Django exposes the default +SQLite behavior and you should be aware of this when doing case-insensitive or +substring filtering. .. _documented at sqlite.org: http://www.sqlite.org/faq.html#q18 diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index 0a8adf6446..729efc1aa2 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -1476,8 +1476,12 @@ SQL equivalent:: Note this will match the headline ``'Today Lennon honored'`` but not ``'today lennon honored'``. -SQLite doesn't support case-sensitive ``LIKE`` statements; ``contains`` acts -like ``icontains`` for SQLite. +.. admonition:: SQLite users + + SQLite doesn't support case-sensitive ``LIKE`` statements; ``contains`` + acts like ``icontains`` for SQLite. See the :ref:`database note + <sqlite-string-matching>` for more information. + .. fieldlookup:: icontains |