Could you check something for me? What table engine are you using for your different databases. Are they both on InnoDB, or is one on MyISSAM?

They are supposed to be both on InnoDB. I recheck my settings (directly and via the django shell, to be sure they are loaded correctly) and everything seem fine. I have 'OPTIONS': {'init_command': 'SET storage_engine=INNODB'} for both. If you need more info, just ask.

Okay, I really can't reproduce this.

If you can find some means of differentiating between your two setups, I'll investigate further. Until then, I'm chalking it up to some weird bug in a MySQL release, and marking it as WorksForMe

I did more tests and things get a bit weird.

Firstly, I ran the tests in a virtual server (VirtualBox) that's an exact copy of the production server (Ubuntu 10.04 64bit, etc. I did the installation on both, the virtual and the production by running the same script). So they are really similar on the software side. But I don't have the problem on the virtual server but keep getting it on the production one?

Secondly, I saw this warning (not a traceback) that I didn't remark the other time (but I'm pretty sure it was there):

./home/mmac/virtualenvs/staging/lib/python2.6/site-packages/django/db/backends/mysql/base.py:86: Warning: Column 'name' cannot be null
return self.cursor.execute(query, args)

Weird, if I'm not wrong, that's the error that the try (line 102) is supposed to catch. So, as the try is not catching the error, the transaction.rollback() is not executed and the test fail. The tryis not catching the error because it's not an error but a warning. Now I need to find why the django mysql backend give a warning instead of an error. It surely have something to do with this comment in the mysql backend code:

# MySQLdb-1.2.1 and newer automatically makes use of SHOW WARNINGS on
# MySQL-4.1 and newer, so the MysqlDebugWrapper is unnecessary. Since the
# point is to raise Warnings as exceptions, this can be done with the Python
# warning module, and this is setup when the connection is created, and the
# standard util.CursorDebugWrapper can be used. Also, using sql_mode
# TRADITIONAL will automatically cause most warnings to be treated as errors.

But it's not clear to me what's the problem and what's the difference between my 2 setup that trigger 2 different behaviors. If you have any idea, tell me.

Okay, I've updated the unit test so that this inconsistency isn't a problem.

Very weird though. More and more, I'm convinced that database abstraction layers in general are more trouble then they're worth.