Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

[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 Morales authored December 02, 2010

Showing 1 changed file with 17 additions and 15 deletions. Show diff stats Hide diff stats

  1. 32  docs/ref/databases.txt
32  docs/ref/databases.txt
@@ -208,18 +208,19 @@ non-unique) with the default collation.
208 208
 In many cases, this default will not be a problem. However, if you really want
209 209
 case-sensitive comparisons on a particular column or table, you would change
210 210
 the column or table to use the ``utf8_bin`` collation. The main thing to be
211  
-aware of in this case is that if you are using MySQLdb 1.2.2, the database backend in Django will then return
212  
-bytestrings (instead of unicode strings) for any character fields it returns
213  
-receive from the database. This is a strong variation from Django's normal
214  
-practice of *always* returning unicode strings. It is up to you, the
215  
-developer, to handle the fact that you will receive bytestrings if you
216  
-configure your table(s) to use ``utf8_bin`` collation. Django itself should work
217  
-smoothly with such columns, but if your code must be prepared to call
218  
-``django.utils.encoding.smart_unicode()`` at times if it really wants to work
219  
-with consistent data -- Django will not do this for you (the database backend
220  
-layer and the model population layer are separated internally so the database
221  
-layer doesn't know it needs to make this conversion in this one particular
222  
-case).
  211
+aware of in this case is that if you are using MySQLdb 1.2.2, the database
  212
+backend in Django will then return bytestrings (instead of unicode strings) for
  213
+any character fields it receive from the database. This is a strong variation
  214
+from Django's normal practice of *always* returning unicode strings. It is up
  215
+to you, the developer, to handle the fact that you will receive bytestrings if
  216
+you configure your table(s) to use ``utf8_bin`` collation. Django itself should
  217
+mostly work smoothly with such columns (except for the ``contrib.sessions``
  218
+``Session`` and ``contrib.admin`` ``LogEntry`` tables described below), but
  219
+your code must be prepared to call ``django.utils.encoding.smart_unicode()`` at
  220
+times if it really wants to work with consistent data -- Django will not do
  221
+this for you (the database backend layer and the model population layer are
  222
+separated internally so the database layer doesn't know it needs to make this
  223
+conversion in this one particular case).
223 224
 
224 225
 If you're using MySQLdb 1.2.1p2, Django's standard
225 226
 :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
230 231
 the data is read in from the database. This problem was `fixed in MySQLdb
231 232
 1.2.2`_, so if you want to use :class:`~django.db.models.TextField` with
232 233
 ``utf8_bin`` collation, upgrading to version 1.2.2 and then dealing with the
233  
-bytestrings (which shouldn't be too difficult) is the recommended solution.
  234
+bytestrings (which shouldn't be too difficult) as described above is the
  235
+recommended solution.
234 236
 
235 237
 Should you decide to use ``utf8_bin`` collation for some of your tables with
236  
-MySQLdb 1.2.1p2, you should still use ``utf8_collation_ci_swedish`` (the
237  
-default) collation for the :class:`django.contrib.sessions.models.Session`
  238
+MySQLdb 1.2.1p2 or 1.2.2, you should still use ``utf8_collation_ci_swedish``
  239
+(the default) collation for the :class:`django.contrib.sessions.models.Session`
238 240
 table (usually called ``django_session``) and the
239 241
 :class:`django.contrib.admin.models.LogEntry` table (usually called
240 242
 ``django_admin_log``). Those are the two standard tables that use

0 notes on commit f8d0145

Please sign in to comment.
Something went wrong with that request. Please try again.