MySQL backend has MySQL-4.0 incompatbiility

[Malcolm Tredinnick]

As reported in ​this django-users thread, we appear to have inadvertently trashed MySQL-4.0 support with the change in [4760].

Hopefully this shouldn't be too hard to fix and it's probably worth doing.

[Andy Dustman <farcepest@…>]

You can't set the character set from the client in MySQL-4.0 and older. And if you don't set the character set to utf8, then you may have a different default character set.

I think what will probably need to be done is to try to trap the exception, and then remove charset from the options (kwargs). There should be some sort of warning if the default character set is not utf8. However, I just checked the implementation, and connection.set_character_set() only tries to change the character set if the current character set is different from the requested one. Therefore anyone who gets this error message has their server configured for something other than utf8.

[Malcolm Tredinnick]

Andy,

In the unicode branch, we are setting use_unicode=True. That's going to be the trunk code shortly, so I'm sort of filtering any solution for this ticket through what we are doing on that branch. If the caller is passing unicode string objects in, does the value of the character set setting matter in that case (for MySQL-4.0)? There's no preferred answer here, I just want to know so that we get the documentation correct.

[Andy Dustman <farcepest@…>]

use_unicode=True has absolutely no effect on objects passed to execute(). It only affects how text-ish columns are returned from the database. If True, varchar, text, etc., are returned as unicode objects. If False, they are returned as strings. Regardless of the setting, you can always pass unicode objects as parameters, and they are encoded into strings with the connection's character set. So you can always throw unicode objects at MySQLdb; use_unicode only determines whether or not MySQLdb throws unicode objects at you.

The last time I tried the unit tests (at PyCon), turning on use_unicode=True did break some unit tests, but only for superficial reasons, i.e. it was comparing equality for two lists, and one lists had strings and the other unicode, so they compared as unequal.

[Malcolm Tredinnick]

Thanks for the clarification, Andy. We should be able to cobble together some documentation to explain things for the MySQL 4.0 users, then (and work around the error from sending through the bad command for them).

[brain@…]

Is this likely to be fixed anytime soon? I'd love to use Django but this issue is preventing that!

[Yves Junqueira <yves.junqueira@…>]

An ugly workaround for this issue would be to just comment out the kwargscharset setting in django/db/backends/mysql/base.py:

            kwargs = {
                'conv': django_conversions,
            #    'charset': 'utf8',
                'use_unicode': False,
            }

In my case, this is the 83rd line in /usr/lib/python2.3/site-packages/django/db/backends/mysql/base.py

I'm not sure if this may cause charset troubles in your application and I have not tested it extensively with non-ASCII charsets. And of course, this is not a proper fix, it's just a workaround if you are having problems with MySQL 4.0 and Django.

[Malcolm Tredinnick]

Closing for reasons of atrophy. I think there are many reasons we aren't supporting MySQL 4.0 at the moment and comments about this ticket stopped three years ago. If it really worries somebody, we'll probably take a reasonable patch to fix things, but just a wish to fix it isn't appropriate any longer.