Esta resposta é para casos semelhantes, se a resposta principal da Alasdair não ajudar . (Por exemplo, se a migração indesejada for criada em breve novamente a cada nova migração ou se houver uma migração maior que não possa ser revertida ou se a tabela tiver sido removida manualmente.)
... excluir a migração, sem criar uma nova migração?
TL; DR : você pode excluir algumas das últimas migrações revertidas (confusas) e fazer uma nova após corrigir os modelos . Você também pode usar outros métodos para configurá-lo para não criar uma tabela pelo comando migrate. A última migração deve ser criada para corresponder aos modelos atuais .
Casos em que alguém não deseja criar uma tabela para um Modelo que deve existir:
A) Nenhuma tabela deve existir em nenhum banco de dados em nenhuma máquina e sem condições
- Quando: É um modelo base criado apenas para a herança de outro modelo.
- Solução: Definir
class Meta: abstract = True
B) A tabela é criada raramente, por outra coisa ou manualmente de uma maneira especial.
- Solução: Use
class Meta: managed = False
A migração é criada, mas nunca usada, apenas em testes. O arquivo de migração é importante, caso contrário, os testes do banco de dados não podem ser executados, iniciando a partir do estado inicial reproduzível.
C) A tabela é usada apenas em algumas máquinas (por exemplo, em desenvolvimento).
- Solução: Mova o modelo para um novo aplicativo adicionado ao INSTALLED_APPS apenas sob condições especiais ou use uma condição
class Meta: managed = some_switch
.
D) O projeto utiliza vários bancos de dados emsettings.DATABASES
- Solução: escreva um roteador de banco de dados com o método
allow_migrate
para diferenciar os bancos de dados onde a tabela deve ser criada e onde não.
A migração é criada em todos os casos A), B), C), D) com Django 1.9+ (e somente nos casos B, C, D com Django 1.8), mas aplicada ao banco de dados apenas nos casos apropriados ou talvez nunca se necessário. Migrações são necessárias para a execução de testes desde o Django 1.8. O estado atual relevante completo é registrado pelas migrações, mesmo para os modelos com managed = False no Django 1.9+, para ser possível criar uma ForeignKey entre modelos gerenciados / não gerenciados ou para tornar o modelo gerenciado = True mais tarde. (Esta pergunta foi escrita na época do Django 1.8. Tudo aqui deve ser válido para versões entre 1.8 e 2.2.)
Se a última migração não for facilmente revertível, é possível com cautela (após o backup do banco de dados) fazer uma reversão falsa ./manage.py migrate --fake my_app 0010_previous_migration
, exclua a tabela manualmente.
Se necessário, crie uma migração fixa a partir do modelo fixo e aplique-a sem alterar a estrutura do banco de dados ./manage.py migrate --fake my_app 0011_fixed_migration
.