Esta respuesta es para casos similares si la respuesta principal de Alasdair no ayuda . (Por ejemplo, si la migración no deseada se crea pronto nuevamente con cada nueva migración o si se trata de una migración más grande que no se puede revertir o la tabla se ha eliminado manualmente).
... eliminar la migración, sin crear una nueva migración?
TL; DR : puede eliminar algunas de las últimas migraciones revertidas (confusas) y hacer una nueva después de corregir los modelos . También puede usar otros métodos para configurarlo para que no cree una tabla mediante el comando migrate. La última migración debe crearse para que coincida con los modelos actuales .
Casos por los cuales alguien no quiere crear una tabla para un Modelo que debe existir:
A) No debería existir tal tabla en ninguna base de datos en ninguna máquina y sin condiciones
- Cuándo: es un modelo base creado solo para la herencia del modelo de otro modelo.
- Solución: establecer
class Meta: abstract = True
B) La tabla se crea raramente, por otra cosa o manualmente de una manera especial.
- Solución: uso
class Meta: managed = False
La migración se crea, pero nunca se usa, solo en pruebas. El archivo de migración es importante, de lo contrario las pruebas de la base de datos no pueden ejecutarse, comenzando desde el estado inicial reproducible.
C) La tabla se usa solo en algunas máquinas (por ejemplo, en desarrollo).
- Solución: mueva el modelo a una nueva aplicación que se agregue a INSTALLED_APPS solo en condiciones especiales o use un condicional
class Meta: managed = some_switch
.
D) El proyecto utiliza múltiples bases de datos ensettings.DATABASES
- Solución: escriba un enrutador de base de datos con método
allow_migrate
para diferenciar las bases de datos donde se debe crear la tabla y dónde no.
La migración se crea en todos los casos A), B), C), D) con Django 1.9+ (y solo en los casos B, C, D con Django 1.8), pero se aplica a la base de datos solo en los casos apropiados o tal vez nunca si requerido así. Las migraciones han sido necesarias para ejecutar pruebas desde Django 1.8. Las migraciones registran el estado actual relevante completo, incluso para modelos con Managed = False en Django 1.9+ para que sea posible crear una ForeignKey entre modelos administrados / no administrados o para que el modelo sea administrado = True más adelante. (Esta pregunta se ha escrito en el momento de Django 1.8. Todo aquí debería ser válido para versiones entre la 1.8 y la 2.2 actual).
Si la última migración no es (son) fácilmente reversibles, entonces es posible realizar con cautela (después de la copia de seguridad de la base de datos) una reversión falsa ./manage.py migrate --fake my_app 0010_previous_migration
, eliminar la tabla manualmente.
Si es necesario, cree una migración fija desde el modelo fijo y aplíquela sin cambiar la estructura de la base de datos ./manage.py migrate --fake my_app 0011_fixed_migration
.