Django South – table already exists

Django South – table already exists

I am trying to get started with South.  I had an existing database and I added South (syncdb, schemamigration --initial).
Then, I updated to add a field and ran ./ schemamigration myapp --auto. It seemed to find the field and said I could apply this with ./ migrate myapp. But, doing that gave the error: 
django.db.utils.DatabaseError: table "myapp_tablename" already exists

tablename is the first table listed in
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

./ 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 ./ 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:

./ schemamigration myapp --add-field MyModel.added_field
./ 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:

./ migrate myapp 0010

Now try ./ migrate myapp

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


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:

Perform these steps in order may help you:

1) python schemamigration apps.appname –initial

Above step creates migration folder as default.

2) python migrate apps.appname –fake

generates a fake migration.

3) python schemamigration apps.appname –auto

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

4) python migrate apps.appname

Answer 5:

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 file (and erase any data that won’t be recreated by fixtures during migrate): schemamigration myapp --initial migrate myapp --fake migrate myapp zero migrate myapp

This will only delete and recreate database tables that exist in your latest 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: sqlclear myapp | sqlshell

And if that still leaves some CRUFT lying around in your database then you’ll have to do an inspectdb and create the file from that (for the tables and app that you want to clear) before doing the sqlclear and then restore your original 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 6:

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

./ 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 ./ 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).

Answer 7:

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

class Migration(migrations.Migration):

    dependencies = [

    operations = [
        #    name='TABLE',
        #    fields=[
        #            ....
        #            ....
        #    ],


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 sqlmigrate APP_NAME MIGRATION_NAME


$ python 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