Qual è l’approccio consigliato per reimpostare la cronologia delle migrazioni utilizzando Django South?

Ho accumulato parecchie migrazioni usando South (0.7) e Django (1.1.2) che stanno iniziando a consumare un bel po ‘di tempo nei miei test unitari. Vorrei reimpostare la linea di base e avviare una nuova serie di migrazioni. Ho esaminato la documentazione di South , fatto la solita ricerca di Google / StackOverflow (ad esempio “la cronologia di migrazione di django sud (ripristina o cancella o rimuovi)”) e non ho trovato nulla di ovvio.

Un approccio che ho previsto implicherebbe “ricominciare” rimuovendo “Sud” o “cancellando” manualmente la cronologia (ad esempio, cancella la tabella db, rimuovi i file di migrazione dal director delle migrazioni) e ri-esegui semplicemente,

./manage.py schemamigration southtut –initial

Quindi, se qualcuno lo ha già fatto prima e ha qualche consiglio / suggerimento, sarebbe molto apprezzato.

    EDIT – Sto mettendo un commento qui sotto in cima a questo dato che è importante leggerlo prima della> risposta accettata che segue @andybak

    @Dominique: il tuo consiglio riguardo a manage.py reset south è pericoloso e potrebbe distruggere il database se ci sono app di terze parti che utilizzano south nel progetto, come sottolineato da @thnee qui sotto. Dal momento che la tua risposta ha così tanti voti positivi, sarei davvero grata se tu potessi modificarla e aggiungere almeno un avvertimento a riguardo, o (ancora meglio) cambiarla per riflettere l’approccio di @hobs (che è altrettanto comodo, ma non lo fa influire su altre app) – grazie! – chrisv 26 Mar 13 alle 09:09

    Risposta accettata segue di seguito:

    In primo luogo, una risposta dell’autore del Sud :

    Finché si presta attenzione a farlo su tutte le distribuzioni contemporaneamente, non dovrebbe esserci alcun problema con questo. Personalmente, lo farei:

      rm -r appname/migrations/ ./manage.py reset south ./manage.py convert_to_south appname 

    (Nota che la parte ” reset south ” cancella i record di migrazione per TUTTE le app, quindi assicurati di eseguire le altre due linee per tutte le app o di eliminarle selettivamente).

    La chiamata convert_to_south alla fine effettua una nuova migrazione e fake-la applica (poiché il database ha già le tabelle corrispondenti). Non è necessario eliminare tutte le tabelle dell’app durante il processo.

    Ecco cosa sto facendo sul mio server di produzione + dev quando ho bisogno di liberarmi di tutte queste migrazioni di sviluppatori non necessari:

    1. Assicurati di avere lo stesso schema DB su entrambi i lati
    2. elimina ogni cartella di migrazione su entrambi i lati
    3. corri ./manage.py ripristina il sud (come dice il post) su entrambi i lati = cancella il tavolo sud *
    4. eseguire ./manage.py convert_to_south su entrambi i lati (simulare la migrazione 0001)
    5. quindi posso ricominciare a fare migrazioni e spingere le cartelle di migrazione sul mio server

    * eccetto se vuoi pulire solo un’app tra le altre, in tal caso dovrai modificare la tua tabella south_history ed eliminare solo le voci relative alla tua app.

    Se è necessario selezionare in modo selettivo (per una sola app) le migrazioni che impiegano troppo tempo, questo ha funzionato per me.

     rm /migrations/* python manage.py schemamigration  --initial python manage.py migrate  0001 --fake --delete-ghost-migrations 

    Non dimenticare di ripristinare manualmente eventuali dipendenze da altre app aggiungendo linee come depends_on = (("", "0001_initial"),("", "0001_initial")) al tuo /migrations/0001_initial.py file, come primo attributo nella class di migrazione appena sotto la class Migration(SchemaMigration):

    È quindi ansible ./manage.py migrate --fake --delete-ghost-migrations su altri ambienti, per questa risposta SO . Ovviamente se si simula l’eliminazione o il falso della migrate zero è necessario eliminare manualmente le tabelle db rimanenti con una migrazione come questa .

    Un’opzione più nucleare è quella di ./manage.py migrate --fake --delete-ghost-migrations sul server di distribuzione live seguito da un [mio] sqldump. Quindi instradare il dump in [my] sql negli ambienti in cui è necessario il db migrato, completamente popolato. Sacrificio del Sud, lo so, ma ha funzionato per me.

    Grazie alle risposte di Dominique Guardiola e dei piani di cottura, mi ha aiutato a risolvere un problema difficile. Tuttavia ci sono un paio di problemi con la soluzione, ecco la mia opinione su di esso.

    L’utilizzo di manage.py reset south non è una buona idea se hai applicazioni di terze parti che utilizzano South, ad esempio django-cms (praticamente tutto usa South).

    reset south cancellerà tutta la cronologia di migrazione per tutte le app che hai installato.

    Ora considera di eseguire l’aggiornamento all’ultima versione di django-cms , conterrà nuove migrazioni come 0009_do_something.py . South verrà sicuramente confuso quando si tenta di eseguire tale migrazione senza avere da 0001 a 0008 nella cronologia delle migrazioni.

    È molto meglio / più sicuro ripristinare in modo selettivo solo le app che stai mantenendo .


    Prima di tutto, assicurati che le tue app non abbiano desync tra le migrazioni su disco e le migrazioni che sono state eseguite sul database. Altrimenti ci sarà mal di testa.

    1. Elimina la cronologia delle migrazioni per le mie app

     sql> delete from south_migrationhistory where app_name = 'my_app'; 

    2. Elimina le migrazioni per le mie app

     $ rm -rf my_app/migrations/ 

    3. Crea nuove migrazioni iniziali per le mie app

     $ ./manage.py schemamigration --initial my_app 

    4. Fake esegue le migrazioni iniziali per le mie app

    Questo inserisce le migrazioni in south_migrationhistory senza toccare le tabelle attuali:

     $ ./manage.py migrate --fake my_app 

    I passaggi 3 e 4 sono in realtà solo una variante più lunga di manage.py convert_to_south my_app , ma preferisco quel controllo extra, in una situazione così delicata come la modifica del database di produzione.

    Come theeee (vedi la sua risposta), stiamo usando un approccio più gentile al suggerimento dell’autore meridionale (Andrew Godwin) citato altrove, e stiamo separando ciò che facciamo con la base di codice da ciò che facciamo al database, durante la distribuzione , perché abbiamo bisogno che gli schieramenti siano ripetibili:

    Cosa facciamo nel codice:

     # Remove all the migrations from the app $ rm -fR appname/migrations # Make the first migration (don't touch the database) $ ./manage.py schemamigration appname --initial 

    Cosa facciamo al database una volta che il codice è stato distribuito

     # Fake the migration history, wiping out the rest $ ./manage.py migrate appname --fake --delete-ghost-migrations 

    Se stai solo lavorando sulla macchina di sviluppo, ho scritto un comando di gestione che fa più o meno quello che Dominique ha suggerito.

    http://balzerg.blogspot.co.il/2012/09/django-app-reset-with-south.html

    In contrasto con il suggerimento dell’autore meridionale, questo NON AGISCE a altre app installate usando il sud.

    Di seguito è riportato solo se si desidera ripristinare tutte le app. Si prega di eseguire il backup di tutti i database prima di tale lavoro. Annota anche le tue dipend_on nei file iniziali, se ce ne sono.

    Per una volta:

     (1) find . -type d -name migrations -exec git rm -rf '{}' \; (2) find . -type d -name migrations -exec rm -rf '{}' \; (3) ./manage.py schemamigration  --initial (4) [GIT COMMIT] 

    Prova a fare il bootstrap del tuo progetto prima di premere. Quindi, per ogni macchina locale / remota, applicare quanto segue:

     (5) [GIT PULL] (6) ./manage.py reset south (7) ./manage.py migrate --fake 

    Fai l’iniziale (3) per ogni app che vuoi coinvolgere nuovamente. Nota che, reset (6) cancellerà solo la cronologia delle migrazioni, quindi non dannosa per le librerie. Le migrazioni false (7) ripristinano la cronologia delle migrazioni di qualsiasi app di terze parti installata.

    elimina il file necessario dalla cartella dell’app

    percorso di istanza

      cd /usr/local/lib/python2.7/dist-packages/wiki/south_migrations 

    wiki: è la mia app