innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

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
This commit is contained in:
Ramiro Morales 2010-12-02 22:37:15 +00:00
parent 300a5b32e6
commit bb10a5ba79
1 changed files with 17 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
docs/ref/databases.txt
View File

@ -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