22

I wanted to clear out a table in my DB, so I dropped the table. Normally I would do manage.py syncdb to re-create it. However, the answer here says not to use syncdb anymore. So, what do I do instead?

Community
  • 1
  • 1
Claudiu
  • 224,032
  • 165
  • 485
  • 680

5 Answers5

42

It's a pretty late response but for people who will run into the same issue (like I did).

Normally to drop the db_tables for the app that is managed by south you should use:

python manage.py migrate appname zero

But if you dropped them manually in the db let south know about it

python manage.py migrate appname zero --fake

And of course to recreate the tables

python manage.py migrate appname
lehins
  • 9,642
  • 2
  • 35
  • 49
  • I had the same problems as @EliAlbert (only one model dropped). I was able to recover with [the steps in my answer below](http://stackoverflow.com/a/17374887/785400). – Brian Dant Jun 28 '13 at 23:04
  • Just for clarification: *This only works if you dropped every table* . With *every* is meant *every table that corresponds to a model of the specified app*. – Bentley4 Oct 29 '13 at 10:33
27

Had the identical problem. Not sure this works in all circumstances, but here's what I did:

  1. comment out "south" from INSTALLED_APPS
  2. run manage.py syncdb
  3. uncomment "south" in INSTALLED_APPS
  4. run manage.py migrate

Voila!

Your mileage may vary....

DavidG
  • 1,023
  • 11
  • 14
  • you'll need to rename the migrations folder too whilst performing this, I just prefix with an underscore. do this between step 1 and 2 above, then rename back to 'migrations' before step 4 – Adam Spence Feb 26 '15 at 15:26
2

Hmm this exchange covers my very question:

If you modify the database by hand, South won't notice - its only way of keeping track of what version the database is is the south_migrationhistory table, so if you fiddle behind its back, it's your responsibility to fix it.

What I ended up doing was commenting out the model that I dropped in question, doing a schemamigration, creating an empty no-column table of the one I dropped (so South has something to drop), migrateing, then un-commenting the model, schemamigration and migrateing again. A bit more annoying than just dropping the table and syncdb but ah well.

Claudiu
  • 224,032
  • 165
  • 485
  • 680
1

Make sure all your migrations are applied: python manage.py migrate

Tell Django to create the tables as they are in your models: python manage.py syncdb

Tell South that everything is where it should be: python manage.py migrate appname --fake

This assumes that nothing has changed in any of your models since you created your last migration.

Brian Dant
  • 4,029
  • 6
  • 33
  • 47
0

I know this issue is old, but I just ran into this issue and thought I'd post my solution in case this helps anyone.

  1. Go into your models.py folder where the database is.
  2. Cut the entire class out of the models.py file.
  3. Run ./manage.py schemamigration appname --auto (this will create another migration where South will recognize to delete this table). You may need to recreate a blank table in you database so South sees it.
  4. Run the migration and the table should drop from your database.
  5. Re-paste in your table class back to where it was in your models.py file.
  6. Run a ./manage.py schemamigration appname --auto. South should pick up the table and allow you to migrate
  7. Run ./manage.py migrate appname and South should re-add the table back into your databasse... with the columns and such again, but without the data, obviously. :)
jaredgilmore
  • 657
  • 8
  • 17