Django: il comando flush non cancella completamente il database, reset fallisce

Question

Ho riscritto molti dei miei modelli, e dal momento che sto solo eseguendo un server di test, faccio ./manage.py reset myapp per resettare le tabelle db e tutto è stato funziona bene.

Ma ho provato a farlo questa volta, e si ottiene un errore,

"L'errore completo: contraint owner_id_refs_id_9036cedd" di relazione "myapp_tagger" non esiste"

così ho pensato che sarebbe solo nuke l'intero sito e ricominciare. Così ho fatto ./manage.py flush poi ha fatto un syncdb questo non ha generato un errore e cancellato tutti i miei dati, tuttavia non ha aggiornato il database da quando provo ad accedere a uno qualsiasi degli oggetti di my_app , ottengo un errore di colonna non trovato. Ho pensato che flush doveva far cadere tutti i tavoli. Il syncdb ha detto che non sono stati aggiunti fixtures

Suppongo che l'errore sia legato al fatto che ho modificato il modello di tagger in modo che abbia un foreignkey con un proprietario di nome legato ad un altro oggetto.

Ho provato ad aggiungere related_name agli argomenti foreignkey e nulla sembra funzionare.

Answer 1

I thought that flush was supposed to drop all tables.

No. Secondo la documentation, manage.py flush non eliminare le tabelle. Invece lo fa il seguente:

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.

Come indicato nel chapter 10 of The Django Book nella sezione "Modifiche ad uno schema di database",

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.

Pertanto, per risolvere il problema sarà necessario uno:

1. Eliminare il database e riemettere manage.py syncdb. Questo è il processo che utilizzo quando sto ancora sviluppando lo schema del database. Io uso un dispositivo initial_data per installare alcuni dati di test, che devono anche essere aggiornati quando lo schema del database cambia.
2. Rilasciare manualmente i comandi SQL per modificare lo schema del database.
3. Utilizzare South.