--fake-initial vs --fake dans Django migration?
Quelle est la différence entre --fake-initial et --fake in Django migrations? Quels sont les dangers de l'utilisation de fausses migrations? Tout le monde le sait? Merci beaucoup à tous.
J'utilise Django 1.10
Eh bien, la documentation est très claire à ce sujet
--fake-initial
Permet Django d'ignorer la migration initiale d'une application si toutes les tables de base de données avec les noms de tous les modèles créés par toutes les opérations CreateModel dans cette migration existent déjà. Cette option est destinée à être utilisée lors de la première exécution de migrations sur un base de données qui préexistait à l'utilisation des migrations. Cette option ne vérifie cependant pas le schéma de base de données correspondant au-delà des noms de table correspondants
Vous posiez des questions sur les risques, et bien voilà
à utiliser uniquement si vous êtes sûr que votre schéma existant correspond à ce qui est enregistré lors de votre migration initiale.
--faux
Indique Django pour marquer les migrations comme ayant été appliquées ou non appliquées, mais sans réellement exécuter le SQL pour modifier votre schéma de base de données.
Ceci est destiné aux utilisateurs avancés pour manipuler directement l'état de migration actuel s'ils appliquent manuellement des modifications;
Encore une fois, les risques sont clairement mis en évidence
soyez averti que l'utilisation de --fake risque de mettre la table des états de migration dans un état où une récupération manuelle sera nécessaire pour que les migrations s'exécutent correctement.
Cette réponse est valable non seulement pour Django versions 1.8+ mais également pour les autres versions.
modifier novembre 2018: Je vois parfois des réponses ici et ailleurs qui suggèrent que vous devez supprimer votre databae. Ce n'est presque jamais la bonne chose à faire. Si vous supprimez votre base de données, vous perdez toutes vos données.
@ e4c5 a déjà répondu à cette question, mais je voudrais ajouter une dernière chose concernant le moment d'utiliser --fake et --fake-initial.
Supposons que vous disposiez d'une base de données de production et que vous souhaitiez l'utiliser pour le développement et appliquer des migrations sans détruire les données. Dans ce cas --fake-initial est très pratique.
Le --fake-initial forcera Django à regarder vos fichiers de migration et à ignorer la création de tables qui sont déjà dans votre base de données. Notez cependant que toutes les migrations qui ne créent pas de tables (mais modifier plutôt les tables existantes) sera exécuté.
Inversement, si vous avez un projet existant avec des fichiers de migration et que vous souhaitez réinitialiser l'historique des migrations existantes, alors --fake est généralement utilisé.
Réponse courte
--fakene le fait pas applique la migration--fake-initialpeut ou non appliquer la migration
Réponse plus longue:
--fake: Django conserve une table appelée Django_migrations pour savoir quelles migrations il a appliquées par le passé, pour vous empêcher de les réappliquer accidentellement. Tout --fake fait est d'insérer le nom du fichier de migration dans cette table, sans réellement exécuter la migration. Cela est utile si vous avez d'abord modifié manuellement le schéma de la base de données, puis les modèles, et que vous souhaitez contourner les actions de Django. Cependant, pendant cette étape, vous êtes seul, alors faites attention à ne pas vous retrouver dans un état incohérent.
--fake-initial: dépend de l'état de la base de données
- toutes les tables existent déjà dans la base de données: dans ce cas, cela fonctionne comme
--fake. Seuls les noms des tables sont vérifiées, pas leur schéma réel, donc, encore une fois, faites attention - aucune des tables existe déjà dans la base de données: dans ce cas, cela fonctionne comme une migration normale
- ne partie du tablea existe déjà: vous obtenez une erreur. Ce n'est pas censé se produire, soit vous vous occupez de la base de données, soit Django le fait.
Notez que, --fake-initial n'est pris en compte que si le fichier de migration contient initial=True dans sa classe, sinon l'indicateur est ignoré. C'est également la seule utilisation documentée de initial=True dans les migrations.