Cette réponse est pour des cas similaires si la première réponse d'Alasdair n'aide pas . (Par exemple, si la migration indésirable est créée à nouveau à chaque nouvelle migration ou si elle se trouve dans une migration plus importante qui ne peut pas être annulée ou si la table a été supprimée manuellement.)
... supprimer la migration, sans créer de nouvelle migration?
TL; DR : Vous pouvez supprimer quelques dernières migrations annulées (confuses) et en faire une nouvelle après avoir corrigé les modèles . Vous pouvez également utiliser d'autres méthodes pour le configurer afin de ne pas créer de table par commande migrate. La dernière migration doit être créée pour correspondre aux modèles actuels .
Cas où quelqu'un ne veut pas créer une table pour un modèle qui doit exister:
A) Aucune telle table ne devrait exister dans aucune base de données sur aucune machine et aucune condition
- Quand: il s'agit d'un modèle de base créé uniquement pour l'héritage de modèle d'un autre modèle.
- Solution: définir
class Meta: abstract = True
B) La table est créée rarement, par autre chose ou manuellement d'une manière spéciale.
- Solution: Utilisation
class Meta: managed = False
La migration est créée, mais jamais utilisée, uniquement dans les tests. Le fichier de migration est important, sinon les tests de base de données ne peuvent pas s'exécuter, à partir d'un état initial reproductible.
C) La table est utilisée uniquement sur certaines machines (par exemple en développement).
- Solution: déplacez le modèle vers une nouvelle application ajoutée à INSTALLED_APPS uniquement dans des conditions spéciales ou utilisez un conditionnel
class Meta: managed = some_switch
.
D) Le projet utilise plusieurs bases de donnéessettings.DATABASES
- Solution: Écrivez un routeur de base de données avec une méthode
allow_migrate
afin de différencier les bases de données où la table doit être créée et où pas.
La migration est créée dans tous les cas A), B), C), D) avec Django 1.9+ (et seulement dans les cas B, C, D avec Django 1.8), mais appliquée à la base de données uniquement dans les cas appropriés ou peut-être jamais si nécessaire. Les migrations ont été nécessaires pour exécuter des tests depuis Django 1.8. L'état actuel complet pertinent est enregistré par les migrations même pour les modèles avec managed = False dans Django 1.9+ pour être possible de créer une clé étrangère entre les modèles gérés / non gérés ou pour rendre le modèle géré = True plus tard. (Cette question a été écrite à l'époque de Django 1.8. Tout ici devrait être valable pour les versions entre 1.8 et la 2.2 actuelle.)
Si la dernière migration n'est pas (ou n'est pas) facilement réversible, il est possible de faire prudemment (après la sauvegarde de la base de données) un faux rétablissement ./manage.py migrate --fake my_app 0010_previous_migration
, supprimez la table manuellement.
Si nécessaire, créez une migration fixe à partir du modèle fixe et appliquez-la sans modifier la structure de la base de données ./manage.py migrate --fake my_app 0011_fixed_migration
.