Questa risposta è per casi simili se la risposta migliore di Alasdair non aiuta . (Ad esempio se la migrazione indesiderata viene creata di nuovo presto con ogni nuova migrazione o se si trova in una migrazione più grande che non può essere ripristinata o la tabella è stata rimossa manualmente.)
... eliminare la migrazione, senza creare una nuova migrazione?
TL; DR : è possibile eliminare alcune ultime migrazioni ripristinate (confuse) ed eseguirne una nuova dopo aver corretto i modelli . È inoltre possibile utilizzare altri metodi per configurarlo in modo da non creare una tabella tramite il comando migrate. L'ultima migrazione deve essere creata in modo che corrisponda ai modelli correnti .
Casi per cui qualcuno non vuole creare una tabella per un modello che deve esistere:
A) Nessuna tabella di questo tipo dovrebbe esistere in nessun database su nessuna macchina e senza condizioni
- Quando: è un modello di base creato solo per l'eredità del modello di un altro modello.
- Soluzione: impostare
class Meta: abstract = True
B) La tabella viene creata raramente, da qualcos'altro o manualmente in modo speciale.
- Soluzione: utilizzare
class Meta: managed = False
La migrazione viene creata, ma mai utilizzata, solo nei test. Il file di migrazione è importante, altrimenti i test del database non possono essere eseguiti, a partire dallo stato iniziale riproducibile.
C) La tabella viene utilizzata solo su alcune macchine (ad es. In fase di sviluppo).
- Soluzione: spostare il modello in una nuova applicazione che viene aggiunta a INSTALLED_APPS solo in condizioni speciali o utilizzare un condizionale
class Meta: managed = some_switch
.
D) Il progetto utilizza più database insettings.DATABASES
- Soluzione: scrivere un router di database con il metodo
allow_migrate
per differenziare i database in cui la tabella deve essere creata e dove no.
La migrazione viene creata in tutti i casi A), B), C), D) con Django 1.9+ (e solo nei casi B, C, D con Django 1.8), ma applicata al database solo nei casi appropriati o forse mai se richiesto così. Le migrazioni sono state necessarie per l'esecuzione dei test da Django 1.8. Lo stato corrente rilevante completo viene registrato dalle migrazioni anche per i modelli con managed = False in Django 1.9+ per poter creare un ForeignKey tra modelli gestiti / non gestiti o per rendere il modello gestito = Vero in seguito. (Questa domanda è stata scritta al tempo di Django 1.8. Tutto qui dovrebbe essere valido per le versioni dalla 1.8 alla 2.2 attuale.)
Se l'ultima migrazione non è (non è) facilmente ripristinabile ./manage.py migrate --fake my_app 0010_previous_migration
, è possibile eseguire con cautela (dopo il backup del database) un ripristino falso , eliminare manualmente la tabella.
Se necessario, creare una migrazione fissa dal modello fisso e applicarla senza modificare la struttura del database ./manage.py migrate --fake my_app 0011_fixed_migration
.