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 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
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.
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).
./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.
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:
Fake the first migration:
./manage migrate myapp 0001 –fake
Roll with the rest of migrations:
./manage migrate myapp
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.
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
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
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
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.
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).
As temporary solution, you can comment the Table creation in the migration script.
class Migration(migrations.Migration): dependencies = [ (...) ] operations = [ #migrations.CreateModel( # 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;") ]
One more solution(maybe a temporary solution).
$ python manage.py sqlmigrate APP_NAME MIGRATION_NAME
$ 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
- Database Administration Tutorials
- Programming Tutorials & IT News
- Linux & DevOps World
- Entertainment & General News
- Games & eSport