3

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?

Community
  • 1
  • 1
professorDante
  • 2,290
  • 16
  • 26
  • When you run schemamigration subsequent times are you using the --auto modifier? this isn't really advice since I don't know the answer to this problem but when I run into it I typicaally delete my migration history for that app, as well as the migration entry pertaining to the app in the south_migrations table. Then rerun manage.py schemamigration myapp --initial then migrate, subsequent migrations I always use manage.py schemamigration myapp --auto – Chris Hawkes Apr 17 '14 at 19:55
  • @Chris Hawkes -Yeah, I'm using the -auto modifier, but thanks for the suggestion, all help gratefully recieved! – professorDante Apr 17 '14 at 20:09
  • I do this a lot too when i'm working in dev, particularly when first setting up a new project. If you don't have any information in your database, just drop the tables and start over. – Josh Brown Apr 17 '14 at 22:05
  • @JoshBrown - This is sort of the point though, I specifically don't want to drop the db tables, I just want south to be reset to the state of the models now, removing all the spurious schemas. – professorDante Apr 17 '14 at 22:28
  • @professorDante, ahh I see. Maybe this will help? http://stackoverflow.com/questions/6260778/squashing-multiple-south-migrations-into-one-migration – Josh Brown Apr 17 '14 at 23:53
  • @joshbrown I'll take a look now... – professorDante Apr 18 '14 at 00:42

3 Answers3

1

Caveat: it's late here and I'm tired, but it will be something along these lines:

Rather than telling South that you want to migrate an existing app (which implies a schema exists), you can fake-zero the apps, delete the migrations and make a new intitial one for each app and fake apply it. That basically gets South to replace multiple migrations with one per app

$ ./manage.py dumpdata myapp1 myapp2 > dumped.json  # just in case!
$ ./manage.py migrate myapp1 zero --fake
$ ./manage.py migrate myapp2 zero --fake
$ rm /path/to/myapp1/migrations/.py*
$ rm /path/to/myapp2/migrations/.py*
$ ./manage.py schemamigration myapp1 --initial
$ ./manage.py schemamigration myapp2 --initial
$ ./manage.py migrate myapp1 --fake 
$ ./manage.py migrate myapp2 --fake

The new 0001 migrations for myapp1 and myapp2 will have the same result as the multiple ones that actually created the existing schema, so all will fit just fine (as long as there have been no custom SQL migrations etc)

Steve Jalim
  • 11,989
  • 1
  • 37
  • 54
0

Try this code:

rm <app>/migrations/*
python manage.py schemamigration <app> --initial
python manage.py migrate <app> 0001 --fake  --delete-ghost-migrations
laidibug
  • 1,179
  • 8
  • 5
0

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.

Community
  • 1
  • 1
professorDante
  • 2,290
  • 16
  • 26