web-dev-qa-db-fra.com

Quelle est l’approche recommandée pour réinitialiser l’historique de la migration avec Django South?)?

J'ai accumulé pas mal de migrations avec South (0.7) et Django (1.1.2) qui commencent à prendre pas mal de temps dans mes tests unitaires. J'aimerais réinitialiser le baseline et commencer une nouvelle série de migrations.J'ai passé en revue la documentation South , j'ai effectué la recherche habituelle sur Google/Stackoverflow (par exemple, "Django south (reset OR delete = OR remove) historique de la migration ") et n’a rien trouvé d’évident.

Une approche que j'ai envisagée impliquerait de "recommencer" en "supprimant" Sud ou en "effaçant" l'historique manuellement (par exemple, effacer la table de la base de données, supprimer les fichiers de migration du directeur des migrations) et simplement ré-exécuter,

./manage.py schemamigration southtut --initial

Donc, si quelqu'un a déjà fait cela avant et a quelques conseils/suggestions, il serait grandement apprécié.

djangodjango-south
154
Glenn Snyder

EDIT - Je mets un commentaire ci-dessous en haut de cette page car il est important de le lire avant la> réponse acceptée qui suit @andybak

@Dominique: Votre avis concernant manage.py reset South est dangereux et peut détruire la base de données s'il existe une application tierce utilisant South dans le projet, comme indiqué par @thnee ci-dessous. Étant donné que votre réponse a suscité tant de votes positifs, je vous serais reconnaissant de la modifier et d’en ajouter au moins un avertissement à ce sujet, ou (mieux encore) de la modifier pour refléter l’approche @hobs (ce qui est tout aussi pratique, affecter d'autres applications) - merci! - chrisv 26 mars 13 à 9:09

La réponse acceptée suit ci-dessous:

Tout d'abord, ne réponse de l'auteur du Sud :

Tant que vous prenez soin de le faire simultanément sur tous les déploiements, cela ne devrait poser aucun problème. Personnellement, je ferais:

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

(Notez que le “reset south ”Efface les enregistrements de migration pour TOUTES les applications, assurez-vous d’exécuter les deux autres lignes pour toutes les applications ou de les supprimer de manière sélective).

Le convert_to_south appel à la fin fait une nouvelle migration et fake-l'applique (puisque votre base de données a déjà les tables correspondantes). Il n'est pas nécessaire de supprimer toutes les tables d'application pendant le processus.

Voici ce que je fais sur mon serveur de production dev + lorsque je dois me débarrasser de toutes ces migrations de développeurs inutiles:

  1. Assurez-vous que nous avons le même schéma de base de données des deux côtés
  2. supprimer tous les dossiers de migration des deux côtés
  3. lancez ./manage.py reset sud (comme le dit le post) des deux côtés = efface la table sud *
  4. lancez ./manage.py convert_to_south des deux côtés (simulation de migration 0001)
  5. alors je peux recommencer à faire des migrations et pousser les dossiers de migrations sur mon serveur

* sauf si vous ne souhaitez nettoyer qu'une application parmi d'autres, le cas échéant, vous devrez modifier votre table south_history et supprimer uniquement les entrées relatives à votre application.

122
Dominique Guardiola

Si vous devez sélectivement (pour une seule application) réinitialiser les migrations qui prennent trop de temps, this a fonctionné pour moi.

rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake  --delete-ghost-migrations

N'oubliez pas de restaurer manuellement les dépendances sur d'autres applications en ajoutant des lignes telles que depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial")) à votre fichier <app-dir>/migrations/0001_initial.py, En tant que premier attribut de votre classe de migration juste en dessous class Migration(SchemaMigration):.

Vous pouvez alors ./manage.py migrate <app-name> --fake --delete-ghost-migrations Sur d'autres environnements, par this SO answer . Bien sûr, si vous simulez la suppression ou simulez le migrate zero vous devrez supprimer manuellement les tables de base de données restantes avec une migration telle que this .

Une option plus nucléaire consiste à ./manage.py migrate --fake --delete-ghost-migrations Sur le serveur de déploiement actif suivi d'un [my] sqldump. Puis dirigez ce vidage vers [my] sql sur les environnements dans lesquels vous avez besoin de la base de données migrée et entièrement peuplée. Sacrilège du Sud, je sais, mais a travaillé pour moi.

188
hobs

Grâce aux réponses de Dominique Guardiola et des tables de cuisson, cela m'a aidé à résoudre un problème difficile. Cependant, il y a quelques problèmes avec la solution, voici mon point de vue.

En utilisant manage.py reset south est pas une bonne idée si vous avez applications tierces qui utilise South, par exemple Django-cms _ (essentiellement tout utilise Sud).

reset south supprime tout l'historique de migration de toutes les applications que vous avez installées.

Maintenant, considérons que vous mettez à niveau vers la dernière version de Django-cms, il contiendra de nouvelles migrations comme 0009_do_something.py. Sud sera sûrement dérouté lorsque vous essayez d'exécuter cette migration sans avoir 0001 à travers 0008 dans l'historique de la migration.

Il est bien mieux/plus sûr de réinitialiser de manière sélective uniquement les applications qui que vous maintenez.

Tout d'abord, assurez-vous que vos applications ne comportent aucune désynchronisation entre les migrations sur disque et les migrations exécutées sur la base de données. Sinon, vous aurez mal à la tête.

1. Supprimer l'historique de migration de mes applications

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

2. Supprimer les migrations de mes applications

$ rm -rf my_app/migrations/

3. Créer de nouvelles migrations initiales pour mes applications

$ ./manage.py schemamigration --initial my_app

4. Fake exécuter les migrations initiales pour mes applications

Ceci insère les migrations dans south_migrationhistory sans toucher aux tables réelles:

$ ./manage.py migrate --fake my_app

Les étapes 3 et 4 ne sont en réalité qu'une variante plus longue de manage.py convert_to_south my_app, mais je préfère ce contrôle supplémentaire dans une situation aussi délicate que la modification de la base de données de production.

54
thnee

Comme thnee (voir sa réponse), nous utilisons une approche plus douce à la suggestion de l'auteur du Sud (Andrew Godwin) citée ailleurs ici, et nous séparons ce que nous faisons avec la base de code de ce que nous faisons avec la base de données, lors du déploiement. , car nous avons besoin que les déploiements soient reproductibles:

Ce que nous faisons dans le code:

# 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

Ce que nous faisons à la base de données une fois ce code déployé

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

Si vous travaillez juste sur la machine de développement, j’ai écrit une commande de gestion qui fait à peu près ce que Dominique a suggéré.

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

Contrairement à ce que suggère l'auteur du sud, cela ne nuira pas aux autres applications installées utilisant le sud.

1
idanzalz

supprimer le fichier nécessaire du dossier de l'application

chemin d'instance

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

wiki -est mon application

0
Andrei Eremchuk

Ce qui suit est seulement si vous voulez réinitialiser toutes les applications. Veuillez sauvegarder toutes vos bases de données avant ce travail. Notez également votre depend_on dans les fichiers initiaux s’il en existe.

Pour une fois:

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

Testez le démarrage de votre projet avant le Push. Ensuite, pour chaque ordinateur local/distant, appliquez les actions suivantes:

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

Faites les initiales (3) pour chaque application que vous souhaitez réimpliquer. Notez que reset (6) ne supprimera que l'historique des migrations, donc sans danger pour les bibliothèques. Les fausses migrations (7) remettront l'historique de migration de toutes les applications tierces installées.

0
placeohlder