Django South - table already exists

Question

I am trying to get started with South. I had an existing database and I added South (syncdb, schemamigration --initial).

Then, I updated models.py to add a field and ran ./manage.py schemamigration myapp --auto. It seemed to find the field and said I could apply this with ./manage.py migrate myapp. But, doing that gave the error:

django.db.utils.DatabaseError: table "myapp_tablename" already exists

tablename is the first table listed in models.py.

I am running Django 1.2, South 0.7

Answer 1

since you already have the tables created in the database, you just need to run the initial migration as fake

./manage.py migrate myapp --fake

make sure that the schema of models is same as schema of tables in database.

Answer 2

Although the table "myapp_tablename" already exists error stop raising after I did ./manage.py migrate myapp --fake, the DatabaseError shows no such column: myapp_mymodel.added_field.

Got exactly the same problem!

1.Firstly check the migration number which is causing this. Lets assume it is: 0010.

2.You need to:

./manage.py schemamigration myapp --add-field MyModel.added_field
./manage.py migrate myapp

if there is more than one field missing you have to repeat it for each field.

3.Now you land with a bunch of new migrations so remove their files from myapp/migrations (0011 and further if you needed to add multiple fields).

4.Run this:

./manage.py migrate myapp 0010

Now try ./manage.py migrate myapp

If it doesn't fail you're ready. Just doublecheck if any field's aren't missing.

EDIT:

This problem can also occur when you have a production database for which you install South and the first, initial migration created in other enviorment duplicates what you already have in your db. The solution is much easier here:

1. Fake the first migration:

   ./manage migrate myapp 0001 --fake

2. Roll with the rest of migrations:

   ./manage migrate myapp

Answer 3

When I ran into this error, it had a different cause.

In my case South had somehow left in my DB a temporary empty table, which is used in _remake_table(). Probably I had aborted a migration in a way I shouldn't have. In any case, each subsequent new migration, when it called _remake_table(), was throwing the error sqlite3.pypysqlite2.dbapi2.OperationalError: table "_south_new_myapp_mymodel" already exists, because it did already exist and wasn't supposed to be there.

The _south_new bit looked odd to me, so I browsed my DB, saw the table _south_new_myapp_mymodel, scratched my head, looked at South's source, decided it was junk, dropped the table, and all was well.

Answer 4

If you have problems with your models not matching your database, like @pielgrzym, and you want to automatically migrate the database to match the latest models.py file (and erase any data that won't be recreated by fixtures during migrate):

manage.py schemamigration myapp --initial
manage.py migrate myapp --fake
manage.py migrate myapp zero
manage.py migrate myapp

This will only delete and recreate database tables that exist in your latest models.py file, so you may have garbage tables in your database from previous syncdbs or migrates. To get rid of those, precede all these migrations with:

manage.py sqlclear myapp | manage.py sqlshell

And if that still leaves some CRUFT lying around in your database then you'll have to do an inspectdb and create the models.py file from that (for the tables and app that you want to clear) before doing the sqlclear and then restore your original models.py before creating the --initial migration and migrating to it. All this to avoid messing around with the particular flavor of SQL that your database needs.

Answer 5

Perform these steps in order may help you:

1) python manage.py schemamigration apps.appname --initial

Above step creates migration folder as default.

2) python manage.py migrate apps.appname --fake

generates a fake migration.

3) python manage.py schemamigration apps.appname --auto

Then you can add fields as you wish and perform the above command.

4) python manage.py migrate apps.appname

Answer 6

If you have an existing database and app you can use the south conversion command

./manage.py convert_to_south myapp

This has to be applied before you do any changes to what is already in the database.

The convert_to_south command only works entirely on the first machine you run it on. Once you’ve committed the initial migrations it made into your VCS, you’ll have to run ./manage.py migrate myapp 0001 --fake on every machine that has a copy of the codebase (make sure they were up-to-date with models and schema first). ref: http://south.readthedocs.org/en/latest/convertinganapp.html

Answer 7

As temporary solution, you can comment the Table creation in the migration script.

class Migration(migrations.Migration):

    dependencies = [
        (...)
    ]

    operations = [
        #migrations.CreateModel(
        #    name='TABLE',
        #    fields=[
        #            ....
        #            ....
        #    ],
        #),
        ....
        ....

---

Or

If the existing table contains no rows (empty), then consider deleting the table like below. (This fix is recommended only if the table contains no rows). Also make sure this operation before the createModel operation.

class Migration(migrations.Migration):

    dependencies = [
        (...),
    ]

    operations = [
        migrations.RunSQL("DROP TABLE myapp_tablename;")
    ]

Answer 8

One more solution(maybe a temporary solution).

$ python manage.py sqlmigrate APP_NAME MIGRATION_NAME

eg.,.

$ python manage.py sqlmigrate users 0029_auto_20170310_1117

This will list all the migrations in raw sql queries. You can pick the queries which you want to run avoiding the part which creates the existing table