ansaurus

Question

mysql exception when synchronizing db with django's manage.py script

Answer 1

A:

The traceback is happening during the creation of a django.contrib.auth.Permission: some of these get created for your models automatically as part of syncdb.

Permission.name has max_length=50, so you probably have an application and/or model class with a really long name?

Try the following query in manage.py dbshell:

SELECT * FROM auth_permission WHERE LENGTH(name) = 50;

Piet Delport 2010-10-06 22:40:42

@Piet: brilliant diagnosis!. How did you work out that the exception was being thrown during the creation of django.contrib.auth.Permission ? (I cant see that in the stack trace). In any case, I run the SQL statement you suggested (one row was returned), and indeed I saw that one of the model names has been truncated. How may I fix this?

skyeagle 2010-10-06 23:20:03

The stacktrace references this code: http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/management/__init__.py#L28 , which is creating an object in the Permission model, belonging to the auth application (and thus the auth_permission table).

Craig Trader 2010-10-07 03:18:18

Thanks for the clarification

skyeagle 2010-10-07 10:27:38

Right: reading the function names, `create_permissions` stands out. Unfortunately, there's no real way to fix this except to shorten the affected name: a Django bug should probably be filed, to increase the name length and/or implement hashing of the excess.

Piet Delport 2010-10-07 11:40:17

Answer 2

A:

As Piet Delport noted, the problem is that your model name is too long.

You're certainly going to have to shorten your model name, and then clean up your database. How you do that depends upon where you are in the development process.

If this is a brand new application, with a dedicated database, and no actual data, the simple answer is to drop and recreate the database, and then re-run python manage.py syncdb.
If you have other tables in the database that need to be left alone, but the tables for your Django have no 'real' data, and can thus be dropped without damage, then you can use manage.py sqlclear to generate SQL DDL to drop all of the Django-generated tables, constraints, and indexes.

Do the following:
```
apps="auth contenttypes sessions sites messages admin <myapp1> <myapp2>"
python manage.py sqlclear ${apps} > clear.sql
```
You can feed the generated script to mysql or python manage.py dbshell. Once that's done, you can re-run python manage.py syncdb.
If you have actual data in your database tables that can't be dropped or deleted: Slap yourself and repeat 100 times "I will never do development against a production database again. I will always back up my databases before changing them." Now you're going to have to hand-code SQL to change the affected table name, as well as anything else that references it and any references in the auth_permissions table and any other Django system tables. Your actual steps will depend entirely upon the state of your database and tables.

Craig Trader 2010-10-07 03:25:32

Thanks for the advice (I am not working on a production db BTW ;) ). I had already done what you suggested -(from Piers post), before you posted it. But thanks for your help anyhow. I would vote your answer up, as it at least confirmed what I did - but I am prevented from doing so (asking for a login)

skyeagle 2010-10-07 10:30:44

ansaurus

tags:

views:

answers:

mysql exception when synchronizing db with django's manage.py script

related questions