Юникод в django: решение
В продолжение предыдущего поста.
Оказалось, что несмотря на использование в базе utf8, при указании collation utf8_bin в сочетании с MySQLdb 1.2.2 django почему-то оставляет прочитанные из базы данные в utf8, не преобразуя в unicode. Меня, конечно же, угораздило указать именно этот порядок сортировки.
Соответственно, экспорт базы в файл, замена utf8_bin на utf8_general_ci, импорт обратно - и всё работает. Побочный эффект: с таким collation база перестаёт различать заглавные и строчные буквы, что может повлиять на уникальные ключи по текстовым полям, но в моём случае это не актуально.
Причём эта фича вполне себе документирована, начиная аж с версии 1.0 и по текущую dev:
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).
Вывод: читайте доку, она рулез!
Очевидно, её вовремя не прочитал не только я, но и никто из уважаемых участников сообщества, искренне пытавшихся мне помочь ;)
Оказалось, что несмотря на использование в базе utf8, при указании collation utf8_bin в сочетании с MySQLdb 1.2.2 django почему-то оставляет прочитанные из базы данные в utf8, не преобразуя в unicode. Меня, конечно же, угораздило указать именно этот порядок сортировки.
Соответственно, экспорт базы в файл, замена utf8_bin на utf8_general_ci, импорт обратно - и всё работает. Побочный эффект: с таким collation база перестаёт различать заглавные и строчные буквы, что может повлиять на уникальные ключи по текстовым полям, но в моём случае это не актуально.
Причём эта фича вполне себе документирована, начиная аж с версии 1.0 и по текущую dev:
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).
Вывод: читайте доку, она рулез!
Очевидно, её вовремя не прочитал не только я, но и никто из уважаемых участников сообщества, искренне пытавшихся мне помочь ;)
