Quelle est l'approche recommandée pour réinitialiser L'histoire des migrations en utilisant Django South?

si vous devez sélectivement (pour une seule application) Réinitialiser les migrations qui prennent trop de temps, ce 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 toute dépendances sur d'autres applications en ajoutant des lignes comme depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial")) à votre fichier <app-dir>/migrations/0001_initial.py , comme premier attribut dans votre classe de migration juste au-dessous de class Migration(SchemaMigration): .

vous pouvez ensuite ./manage.py migrate <app-name> --fake --delete-ghost-migrations sur d'autres environnements, par cette SORTE de réponse . Bien sûr, si vous falsifiez la suppression ou la falsification du migrate zero vous aurez besoin de supprimer manuellement toutes les tables db avec une migration comme ce .

une option plus nucléaire est ./manage.py migrate --fake --delete-ghost-migrations sur le serveur de déploiement en direct suivi d'un [my]sqldump. Ensuite, insérez ce dump dans [my]sql sur les environnements où vous avez besoin du db migré, entièrement peuplé. South sacrilege, je sais, mais ça a marché pour moi.

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

utiliser manage.py reset south est pas une bonne idée si vous avez n'importe quel applications de tiers qui utilise le sud, par exemple django-cms (essentiellement tout utilise le Sud).

reset south supprimera tout historique de migration pour toutes les applications que vous avez installés.

maintenant considérer que vous mettez à jour à la dernière version de django-cms , il contiendra de nouvelles migrations comme 0009_do_something.py . Sud sera certainement confus lorsque vous essayez de gérer cette migration sans avoir 0001 à 0008 dans l'histoire de la migration.

C'est beaucoup mieux/plus sûr de manière sélective réinitialiser uniquement les applications que vous êtes le maintien de .

tout d'abord, assurez-vous que vos applications n'ont pas de desync entre les migrations sur disque, et les migrations qui ont été exécutées sur la base de données. Sinon, il y aura des maux de 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 pour 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

Etape 3 et 4 est en fait juste 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.

comme thnee (voir sa réponse), nous utilisons une approche plus douce à la suggestion de L'auteur 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 à la base de données, pendant le déploiement, parce que 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 que le code est déployé

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

si vous travaillez juste sur la machine dev, 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 à la suggestion de l'auteur Sud, cela ne nuira pas aux autres applications installées utilisant south.

ci-dessous est seulement si vous voulez réinitialiser toutes les applications. Veuillez sauvegarder toutes vos bases de données avant ce travail. Notez aussi votre depends_on dans les fichiers initiaux s'il y en a.

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]

tester bootstrapping votre projet avant de pousser. Ensuite, pour chaque machine locale/distante, appliquer ce qui suit:

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

N'initiale (3) chaque app vous voulez ré-impliquer. Notez que, reset (6) permet de supprimer uniquement l'histoire de la migration, donc pas nocif pour les bibliothèques. Fake migrations (7) remettra en mémoire l'historique de migration de toute application tierce installée.

supprimer le fichier nécessaire du dossier app

chemin d'instance

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

wiki -est l'une de mes applications