From bb10a5ba79ecaea7d32b62afe90e83407adf0b74 Mon Sep 17 00:00:00 2001 From: Ramiro Morales Date: Thu, 2 Dec 2010 22:37:15 +0000 Subject: [PATCH] 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 --- docs/ref/databases.txt | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index 1406b7447e..ef0d78ac02 100644 --- a/docs/ref/databases.txt +++ b/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