Comment simplifier les migrations dans Django 1.7?

Il y a déjà des questions similaires pour South, mais j’ai commencé mon projet avec Django 1.7 et je n’utilise pas South.

Au cours du développement, de nombreuses migrations ont été créées, mais le logiciel n’est pas encore dissortingbué et il n’existe aucune firebase database à migrer. Par conséquent, je voudrais réinitialiser les migrations comme si mon modèle actuel était l’original et recréer toutes les bases de données.

Quelle est la manière recommandée de le faire?

EDIT: A partir de Django 1.8, il existe une nouvelle commande nommée squashmigrations qui résout plus ou moins le problème décrit ici.

Dans la version de migration de Django 1.7, la fonctionnalité de réinitialisation qui existait dans le Sud a été abandonnée au profit de nouvelles fonctionnalités pour «écraser» vos migrations. Ceci est censé être un bon moyen de contrôler le nombre de migrations.

https://docs.djangoproject.com/en/dev/topics/migrations/#squashing-migrations

Si vous voulez toujours vraiment repartir à zéro, je suppose que vous pouvez toujours vider la table des migrations et supprimer les migrations après lesquelles vous exécuterez à nouveau makemigrations .

J’ai eu ça. Je viens de comprendre cela et c’est bon.

  • Tout d’abord, pour effacer la table des migrations:

     ./manage.py migrate --fake  zero 
  • Supprimez l’ app-name/migrations/ folder ou le contenu.

  • Faire les migrations:

     ./manage.py makemigrations  
  • Enfin, rangez vos migrations sans apporter d’autres modifications à la firebase database:

     ./manage.py migrate --fake  

J’ai juste eu le même problème. Voici ma solution de contournement.

 #!/bin/sh echo "Starting ..." echo ">> Deleting old migrations" find . -path "*/migrations/*.py" -not -name "__init__.py" -delete find . -path "*/migrations/*.pyc" -delete # Optional echo ">> Deleting database" find . -name "db.sqlite3" -delete echo ">> Running manage.py makemigrations" python manage.py makemigrations echo ">> Running manage.py migrate" python manage.py migrate echo ">> Done" 

La commande find : http://unixhelp.ed.ac.uk/CGI/man-cgi?find

En supposant que ceci est la structure de votre projet,

 project_root/ app1/ migrations/ app2/ migrations/ ... manage.py remove_migrations.py 

vous pouvez exécuter le script remove_migrations.py à partir de l’emplacement indiqué ci-dessus pour supprimer tous les fichiers de migration.

 #remove_migrations.py """ Run this file from a Django =1.7 project root. Removes all migration files from all apps in a project. """ from unipath import Path this_file = Path(__file__).absolute() current_dir = this_file.parent dir_list = current_dir.listdir() for paths in dir_list: migration_folder = paths.child('migrations') if migration_folder.exists(): list_files = migration_folder.listdir() for files in list_files: split = files.components() if split[-1] != Path('__init__.py'): files.remove() 

La suppression manuelle peut être fatigante si vous avez un projet élaboré. Cela m’a sauvé beaucoup de temps. La suppression des fichiers de migration est sécurisée. Je l’ai fait énormément de fois sans rencontrer de problèmes … pour le moment.

Cependant, lorsque j’ai supprimé le dossier des migrations, makemigrations ou migrate n’a pas créé le dossier pour moi. Le script s’assure que le dossier de migration avec son __init__.py rest en place, supprimant uniquement les fichiers de migration.

  1. Supprimer les fichiers: delete_migrations.py (à la racine de prj):
 import os for root, dirs, files in os.walk(".", topdown=False): for name in files: if '/migrations' in root and name != '__init__.py': os.remove(os.path.join(root, name)) 
  1. DELETE FROM django_migrations Where app in ('app1', 'app2');

  2. ./manage.py makemigrations

  3. ./manage.py migrer –fake

OU, vous pouvez écrire la migration de tout cela

J’essaie différentes commandes et certaines des réponses m’aident. Seule cette séquence dans mon cas a corrigé les dépendances brisées dans les migrations dans MYAPP et nettoyé toutes les migrations passées à partir de zéro.

Avant de faire cela, assurez-vous que la firebase database est déjà synchronisée (par exemple, n’ajoutez pas un nouveau champ Model ou modifiez les options Meta).

 rm -Rf MYAPP/migrations/* python manage.py makemigrations --empty MYAPP python manage.py makemigrations python manage.py migrate --fake MYAPP 0002 

Où 0002 est le numéro de migration renvoyé par la dernière commande makemigrations.

Vous pouvez maintenant exécuter makemigrations / migrate à nouveau normalement car la migration 0002 est stockée mais n’est pas reflétée dans la firebase database déjà synchronisée.

Si vous ne vous souciez pas des migrations précédentes, pourquoi ne pas supprimer toutes les migrations dans le répertoire migrations /? vous allez commencer la séquence de migration à partir de zéro, en prenant comme référence votre modèle actuel comme si vous aviez écrit le modèle complet maintenant.

Si vous ne me faites pas confiance, essayez de les supprimer.

Un moyen simple est

Accédez à chaque application et supprimez les fichiers de migration.

Ensuite, allez dans la table django-migrtaions de la firebase database et tronquez-la (supprimez toutes les entrées).

Après cela, vous pouvez créer des migrations à nouveau.

cd vers le répertoire src cd /path/to/src

supprimer les répertoires de migration rm -rf your_app/migrations/

Notez que cela devrait être fait pour chaque application séparément

migrer python3.3 manage.py migrate

si vous souhaitez recommencer python3.3 manage.py makemigrations your_app

Si vous êtes en mode de développement et que vous souhaitez tout réinitialiser (firebase database, migrations, etc.), j’utilise ce script basé sur la réponse d’Abdelhamid Ba. Cela effacera les tables de la firebase database (Postgres), supprimera tous les fichiers de migration, réexécutera les migrations et chargera mes premières installations:

 #!/usr/bin/env bash echo "This will wipe out the database, delete migration files, make and apply migrations and load the intial fixtures." while true; do read -p "Do you wish to continue?" yn case $yn in [Yy]* ) make install; break;; [Nn]* ) exit;; * ) echo "Please answer yes or no.";; esac done echo ">> Deleting old migrations" find ../../src -path "*/migrations/*.py" -not -name "__init__.py" -delete # Optional echo ">> Deleting database" psql -U db_user -d db_name -a -f ./reset-db.sql echo ">> Running manage.py makemigrations and migrate" ./migrations.sh echo ">> Loading initial fixtures" ./load_initial_fixtures.sh echo ">> Done" 

Fichier reset-db.sql:

 DO $$ DECLARE r RECORD; BEGIN -- if the schema you operate on is not "current", you will want to -- replace current_schema() in query with 'schematodeletetablesfrom' -- *and* update the generate 'DROP...' accordingly. FOR r IN (SELECT tablename FROM pg_tables WHERE schemaname = current_schema()) LOOP EXECUTE 'DROP TABLE IF EXISTS ' || quote_ident(r.tablename) || ' CASCADE'; END LOOP; END $$; 

fichier migration.sh:

 #!/usr/bin/env bash cd ../../src ./manage.py makemigrations ./manage.py migrate 

Fichier load_initial_fixtures.sh:

 #!/usr/bin/env bash cd ../../src ./manage.py loaddata ~/path-to-fixture/fixture.json 

Veillez simplement à modifier les chemins d’access correspondant à votre application. J’ai personnellement ces scripts dans un dossier appelé racine_projet / script / local, et les sources de django se trouvent dans racine_projet / src.

Après avoir supprimé chaque dossier “migrations” de mon application (manuellement), j’ai exécuté:

 ./manage.py dbshell delete from django_migrations; 

Ensuite, j’ai pensé que je pouvais faire ./manage.py makemigrations pour les régénérer tous. Cependant, aucun changement n’a été détecté. J’ai ensuite essayé de spécifier une application à la fois: ./manage.py makemigrations foo , ./manage.py makemigrations bar . Cependant, cela a entraîné des dépendances circulaires qui n’ont pas pu être résolues.

Enfin, j’ai lancé une commande makemigrations unique qui spécifiait TOUTES mes applications (sans ordre particulier):

 ./manage.py makemigrations foo bar bike orange banana etc 

Cette fois, cela a fonctionné – les dépendances circulaires ont été automatiquement résolues (il a créé des fichiers de migration supplémentaires si nécessaire).

Ensuite, j’ai pu exécuter ./manage.py migrate --fake et ./manage.py migrate --fake retourné en activité.