Command 'python manage.py init' doesn't work with MySQL 5.0.17/18 under Windows

[quarkcool@…]

Hi everyone, I think I've found a bug.

The problem

Today I checked out the magic-removal branch and tried to use it. I started a project (with django-admin.py startproject), I changed settings.py to add the correct database settings, and then I tried to initialize the database (with python manage.py init). The following error was displayed :

Error: models couldn't be installed. Possible reasons:
  * The database isn't running or isn't configured correctly.
  * At least one of the database tables already exists.
  * The SQL was invalid.
Hint: Look at the output of 'django-admin.py sqlall models'. That's the SQL this command wasn't able to run.
The full error: (1005, "Can't create table '.\\django\\#sql-780_6b.frm' (errno: 150)")
Error: The database couldn't be initialized.
Traceback (most recent call last):

  File "C:\Program Files\Python\lib\site-packages\django\core\management.py", line 494, in init
    install(auth_app)

  File "C:\Program Files\Python\lib\site-packages\django\core\management.py", line 548, in install
    sys.exit(1)

SystemExit: 1

After a little search on my own, I found that the following SQL query :

ALTER TABLE `auth_message` ADD CONSTRAINT `user_id_referencing_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`);

was the source of the problem. Indeed, MySQL complained because the user_id field wasn't exactly the same type as the id field in table auth_user.

The temporary solution

I managed to install the auth app by manually entering the output of python manage.py sqlall auth and adding the following query before the one that caused the problem :

ALTER TABLE `auth_message` CHANGE `user_id` `user_id` MEDIUMINT( 9 ) UNSIGNED NOT NULL 

The type of user_id and the type of auth_user.id were now equivalent, and the query succeeded without problem.

So that's it, I don't think that using Windows is the problem here, maybe I'll try on Linux with the appropriate version of MySQL.

If this can be reproduced, that's a big problem because it means you can't initialize a project with the latest MySQL 5.0.

Thanks for your time

[sj@…]

I can confirm this with MySQL 4.1.12 under Linux. The auto-generated primary key should be an INT(11), just as the foreign key field. Right now primary keys are generated as MEDIUMINT(9).

[Andy Dustman <farcepest@…>]

Ticket #1500 has a patch for this issue.

[Adrian Holovaty]

Fixed in [2582].