Opened 12 years ago

Closed 8 years ago

#4179 closed (wontfix)

MySQL backend has MySQL-4.0 incompatbiility

Reported by: Malcolm Tredinnick Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Keywords:
Cc: farcepest@…, mir@…, yves.junqueira@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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.

Change History (9)

comment:1 Changed 12 years ago by Simon G. <dev@…>

Triage Stage: UnreviewedAccepted

comment:2 Changed 12 years ago by Andy Dustman <farcepest@…>

Cc: farcepest@… added

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.

comment:3 Changed 12 years ago by Malcolm Tredinnick


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.

comment:4 Changed 12 years ago by 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.

comment:5 Changed 12 years ago by 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).

comment:6 Changed 11 years ago by brain@…

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

comment:7 Changed 11 years ago by mir@…

Cc: mir@… added

comment:8 Changed 11 years ago by Yves Junqueira <yves.junqueira@…>

Cc: yves.junqueira@… added

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

            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/

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.

comment:9 Changed 8 years ago by Malcolm Tredinnick

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top