Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

[1.2.X] Fixed grammar and tweaked notes about MySQL database/table co…

…llation interaction with text fields. Refs #14417.

Backport of [14779] from trunk

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@14780 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit f8d014504f9ff003fe3ec28ccc9dcb129974ff09 1 parent 6690e08
@ramiro ramiro authored
Showing with 17 additions and 15 deletions.
  1. +17 −15 docs/ref/databases.txt
View
32 docs/ref/databases.txt
@@ -208,18 +208,19 @@ non-unique) with the default collation.
In many cases, this default will not be a problem. However, if you really want
case-sensitive comparisons on a particular column or table, you would change
the column or table to use the ``utf8_bin`` collation. The main thing to be
-aware of in this case is that if you are using MySQLdb 1.2.2, the database backend in Django will then return
-bytestrings (instead of unicode strings) for any character fields it returns
-receive from the database. This is a strong variation from Django's normal
-practice of *always* returning unicode strings. It is up to you, the
-developer, to handle the fact that you will receive bytestrings if you
-configure your table(s) to use ``utf8_bin`` collation. Django itself should work
-smoothly with such columns, but if your code must be prepared to call
-``django.utils.encoding.smart_unicode()`` at times if it really wants to work
-with consistent data -- Django will not do this for you (the database backend
-layer and the model population layer are separated internally so the database
-layer doesn't know it needs to make this conversion in this one particular
-case).
+aware of in this case is that if you are using MySQLdb 1.2.2, the database
+backend in Django will then return bytestrings (instead of unicode strings) for
+any character fields it receive from the database. This is a strong variation
+from Django's normal practice of *always* returning unicode strings. It is up
+to you, the developer, to handle the fact that you will receive bytestrings if
+you configure your table(s) to use ``utf8_bin`` collation. Django itself should
+mostly work smoothly with such columns (except for the ``contrib.sessions``
+``Session`` and ``contrib.admin`` ``LogEntry`` tables described below), but
+your code must be prepared to call ``django.utils.encoding.smart_unicode()`` at
+times if it really wants to work with consistent data -- Django will not do
+this for you (the database backend layer and the model population layer are
+separated internally so the database layer doesn't know it needs to make this
+conversion in this one particular case).
If you're using MySQLdb 1.2.1p2, Django's standard
:class:`~django.db.models.CharField` class will return unicode strings even
@@ -230,11 +231,12 @@ the information needed to make the necessary conversions isn't available when
the data is read in from the database. This problem was `fixed in MySQLdb
1.2.2`_, so if you want to use :class:`~django.db.models.TextField` with
``utf8_bin`` collation, upgrading to version 1.2.2 and then dealing with the
-bytestrings (which shouldn't be too difficult) is the recommended solution.
+bytestrings (which shouldn't be too difficult) as described above is the
+recommended solution.
Should you decide to use ``utf8_bin`` collation for some of your tables with
-MySQLdb 1.2.1p2, you should still use ``utf8_collation_ci_swedish`` (the
-default) collation for the :class:`django.contrib.sessions.models.Session`
+MySQLdb 1.2.1p2 or 1.2.2, you should still use ``utf8_collation_ci_swedish``
+(the default) collation for the :class:`django.contrib.sessions.models.Session`
table (usually called ``django_session``) and the
:class:`django.contrib.admin.models.LogEntry` table (usually called
``django_admin_log``). Those are the two standard tables that use
Please sign in to comment.
Something went wrong with that request. Please try again.