Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Fixed grammar and tweaked notes about MySQL database/table collation …

…interaction with text fields. Refs #14417.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@14779 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit bb10a5ba79ecaea7d32b62afe90e83407adf0b74 1 parent 300a5b3
@ramiro ramiro authored
Showing with 17 additions and 15 deletions.
  1. +17 −15 docs/ref/databases.txt
View
32 docs/ref/databases.txt
@@ -227,18 +227,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
@@ -249,11 +250,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.