Django: flush command doesnt completely clear database, reset fails

DantheMan picture DantheMan · Dec 29, 2010 · Viewed 9.6k times · Source

I rewrote a lot of my models, and since I am just running a test server, I do ./manage.py reset myapp to reset the db tables and everything has been working fine.

But I tried to do it this time, and I get an error,

"The full error: contraint owner_id_refs_id_9036cedd" of relation "myapp_tagger" does not exist"

So I figured I would just nuke the whole site and start fresh. So i did ./manage.py flush then did a syncdb this did not raise an error and deleted all my data, however it did not update the database since when I try to access any of my_app's objects, i get a column not found error. I thought that flush was supposed to drop all tables. The syncdb said that no fixtures were added.

I assume the error is related to the fact that I changed the tagger model to having a foreignkey with a name owner tied to another object.

I have tried adding related_name to the foreignkey arguments and nothing seems to be working.

Answer

Matthew Rankin picture Matthew Rankin · Dec 29, 2010

I thought that flush was supposed to drop all tables.

No. According to the documentation, manage.py flush doesn't drop the tables. Instead it does the following:

Returns the database to the state it was in immediately after syncdb was executed. This means that all data will be removed from the database, any post-synchronization handlers will be re-executed, and the initial_data fixture will be re-installed.

As stated in chapter 10 of The Django Book in the "Making Changes to a Database Schema" section,

syncdb merely creates tables that don't yet exist in your database — it does not sync changes in models or perform deletions of models. If you add or change a model's field, or if you delete a model, you’ll need to make the change in your database manually.

Therefore, to solve your problem you will need to either:

  1. Delete the database and reissue manage.py syncdb. This is the process that I use when I'm still developing the database schema. I use an initial_data fixture to install some test data, which also needs to be updated when the database schema changes.
  2. Manually issue the SQL commands to modify your database schema.
  3. Use South.