Search code examples
djangodjango-south

Resetting migrations in south leads to 'table already exists'


OK, this is driving me nuts. I'm trying to remove and reset all my south migrations in my DEV environment for two apps, and start again with a clean slate, as my migrations files list was getting very long and I don't need them, as the models are constantly changing, and it's just DEV. Whatever I try, South constantly complains that the DB tables are already there.

Going on this answer on SO, I first remove my migrations dir entirely from each app:

rm -r <my-app>/migrations

No problem. Then reset the south tables:

python manage.py reset south

Again, no worries.

Now tell south that I want those apps managed:

python manage.py convert_to_south <appname>

All seems fine, it even creates the initial migration and runs the --fake:

Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate CC
- Soft matched migration 0001 to 0001_initial.
Running migrations for CC:
- Migrating forwards to 0001_initial.
> CC:0001_initial
(faked)

OK, so according to my (incorrect) understanding, I now have my existing tables managed by south. South knows that the tables ALREADY exist, as we ran initial as --fake.

Now I add a new field to a model, run schemamigration then migrate on that new schema, and guess what, South complains that the tables already exist.

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

What the hell? What on earth am I doing wrong?


Solution

  • Thanks to all who contributed - it turns out that as I'm using SQlite in dev, It's this that is causing all the issues. See another question on SO for clarification. Answering my own question here as it may be useful for others - I'm switching to mySQL, as the issue I stated above doesnt exist in my PRD env, which uses mySQL. Migration all works seamlessly.