Como mover um modelo entre dois aplicativos Django (Django 1.7)

Então, há cerca de um ano, iniciei um projeto e, como todos os novos desenvolvedores, não me concentrei muito na estrutura, no entanto, agora que estou mais junto com o Django, começou a parecer que o layout do meu projeto, principalmente meus modelos, são horríveis na estrutura .

Eu tenho modelos mantidos principalmente em um único aplicativo e, na verdade, a maioria desses modelos deve estar em seus próprios aplicativos individuais. Tentei resolver isso e movê-los para o sul. No entanto, achei complicado e muito difícil devido às chaves estrangeiras ect.

No entanto, devido ao Django 1.7 e suporte embutido para migrações, existe uma maneira melhor de fazer isso agora?

Estou removendo a resposta antiga, pois pode resultar em perda de dados. Como o ozan mencionou , podemos criar duas migrações, uma em cada aplicativo. Os comentários abaixo deste post se referem à minha resposta antiga.

Primeira migração para remover o modelo do 1º aplicativo.

$ python manage.py makemigrations old_app --empty

Edite o arquivo de migração para incluir essas operações.

class Migration(migrations.Migration):

    database_operations = [migrations.AlterModelTable('TheModel', 'newapp_themodel')]

    state_operations = [migrations.DeleteModel('TheModel')]

    operations = [
      migrations.SeparateDatabaseAndState(
        database_operations=database_operations,
        state_operations=state_operations)
    ]

Segunda migração, que depende da primeira migração e cria a nova tabela no 2º aplicativo. Depois de mover o código do modelo para o segundo aplicativo

$ python manage.py makemigrations new_app 

e edite o arquivo de migração para algo assim.

class Migration(migrations.Migration):

    dependencies = [
        ('old_app', 'above_migration')
    ]

    state_operations = [
        migrations.CreateModel(
            name='TheModel',
            fields=[
                ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
            ],
            options={
                'db_table': 'newapp_themodel',
            },
            bases=(models.Model,),
        )
    ]

    operations = [
        migrations.SeparateDatabaseAndState(state_operations=state_operations)
    ]

Isso pode ser feito com bastante facilidade usando migrations.SeparateDatabaseAndState. Basicamente, usamos uma operação de banco de dados para renomear a tabela simultaneamente com duas operações de estado para remover o modelo do histórico de um aplicativo e criá-lo no outro.

Remover do aplicativo antigo

python manage.py makemigrations old_app --empty

Na migração:

class Migration(migrations.Migration):

    dependencies = []

    database_operations = [
        migrations.AlterModelTable('TheModel', 'newapp_themodel')
    ]

    state_operations = [
        migrations.DeleteModel('TheModel')
    ]

    operations = [
        migrations.SeparateDatabaseAndState(
            database_operations=database_operations,
            state_operations=state_operations)
    ]

Adicionar à nova aplicação

Primeiro, copie o modelo para o novo model.py do aplicativo, depois:

python manage.py makemigrations new_app

Isso gerará uma migração com uma CreateModeloperação ingênua como a única operação. Embrulhe isso em uma SeparateDatabaseAndStateoperação para que não tentemos recriar a tabela. Inclua também a migração anterior como uma dependência:

class Migration(migrations.Migration):

    dependencies = [
        ('old_app', 'above_migration')
    ]

    state_operations = [
        migrations.CreateModel(
            name='TheModel',
            fields=[
                ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
            ],
            options={
                'db_table': 'newapp_themodel',
            },
            bases=(models.Model,),
        )
    ]

    operations = [
        migrations.SeparateDatabaseAndState(state_operations=state_operations)
    ]

Eu encontrei o mesmo problema. A resposta de Ozan me ajudou muito, mas infelizmente não foi suficiente. Na verdade, eu tinha várias ForeignKey vinculadas ao modelo que eu queria mover. Após algumas dores de cabeça, encontrei a solução e resolvi publicá-la para resolver o tempo das pessoas.

Você precisa de mais 2 etapas:

1. Antes de fazer qualquer coisa, mudar toda a sua ForeignKeyligação a TheModelem Integerfield. Então corrapython manage.py makemigrations
2. Depois de seguir os passos de Ozan, converta novamente suas chaves estrangeiras: adie ForeignKey(TheModel) vez de IntegerField(). Em seguida, faça as migrações novamente ( python manage.py makemigrations). Em seguida, você pode migrar e deve funcionar ( python manage.py migrate)

Espero que ajude. Claro que testá-lo no local antes de tentar na produção para evitar surpresas ruins :)

Como eu fiz isso (testado no Django == 1.8, com postgres, provavelmente também 1.7)

Situação

app1.YourModel

mas você deseja que ele vá para: app2.YourModel

1. Copie YourModel (o código) do app1 para o app2.

2. adicione isso ao app2.YourModel:

   Class Meta:
       db_table = 'app1_yourmodel'

3. $ python manage.py makemigrations app2

4. Uma nova migração (por exemplo, 0009_auto_something.py) é feita no app2 com uma instrução migrations.CreateModel (), mova essa instrução para a migração inicial do app2 (por exemplo, 0001_initial.py) (será como sempre esteve lá). E agora remova a migração criada = 0009_auto_something.py

5. Assim como você age, como o app2.YourModel sempre esteve lá, agora remova a existência do app1.YourModel das suas migrações. Significado: comente as instruções CreateModel e todos os ajustes ou migração de dados que você usou depois disso.

6. E, é claro, todas as referências ao app1.YourModel precisam ser alteradas para app2.YourModel através do seu projeto. Além disso, não esqueça que todas as chaves estrangeiras possíveis para app1.YourModel nas migrações devem ser alteradas para app2.YourModel

7. Agora, se você migrar o $ python manage.py, nada mudou, também quando você fizer as migrações do $ python manage.py, nada de novo foi detectado.

8. Agora, o toque final: remova o Class Meta de app2.YourModel e faça $ python manage.py makemigrations app2 && python manage.py migrate app2 (se você olhar para essa migração, verá algo assim :)

       migrations.AlterModelTable(
       name='yourmodel',
       table=None,
   ),

table = None, significa que ele assumirá o nome da tabela padrão, que neste caso será app2_yourmodel.

9. FEITO, com os dados salvos.

PS durante a migração, verá que esse content_type app1.yourmodel foi removido e pode ser excluído. Você pode dizer sim a isso, mas apenas se não o usar. Caso você dependa muito dele para que os FKs desse tipo de conteúdo estejam intactos, ainda não responda sim ou não, mas vá para o banco de dados nesse momento manualmente e remova o tipo de conteúdo app2.yourmodel e renomeie o contenttype app1. yourmodel para app2.yourmodel e continue respondendo não.

Recebo migrações nervosas de codificação manual (conforme exigido pela resposta de Ozan ), de modo que o seguinte combina as estratégias de Ozan e Michael para minimizar a quantidade de codificação manual necessária:

1. Antes de mover qualquer modelo, verifique se você está trabalhando com uma linha de base limpa executando makemigrations.
2. Mova o código do modelo de app1paraapp2

3. Conforme recomendado por @Michael, apontamos o novo modelo para a tabela antiga do banco de dados usando a db_tableopção Meta no modelo "novo":

   class Meta:
       db_table = 'app1_yourmodel'

4. Corra makemigrations. Isso irá gerar CreateModeldentro app2e DeleteModeldentro app1. Tecnicamente, essas migrações se referem exatamente à mesma tabela e removeriam (incluindo todos os dados) e recriariam a tabela.

5. Na realidade, não queremos (ou precisamos) fazer nada com a mesa. Nós apenas precisamos do Django acreditar que a mudança foi feita. Pela resposta de @ Ozan, a state_operationsbandeira SeparateDatabaseAndStatefaz isso. Então, nós envolvemos todas as migrationsentradas NOS DOIS MIGRAÇÕES FILES com SeparateDatabaseAndState(state_operations=[...]). Por exemplo,

   operations = [
       ...
       migrations.DeleteModel(
           name='YourModel',
       ),
       ...
   ]

   torna-se

   operations = [
       migrations.SeparateDatabaseAndState(state_operations=[
           ...
           migrations.DeleteModel(
               name='YourModel',
           ),
           ...
       ])
   ]

6. Você também precisa garantir que a nova CreateModelmigração "virtual" dependa de qualquer migração que realmente tenha criado ou alterado a tabela original . Por exemplo, se suas novas migrações são app2.migrations.0004_auto_<date>(para Create) e app1.migrations.0007_auto_<date>(para Delete), a coisa mais simples a fazer é:

   • Abra app1.migrations.0007_auto_<date>e copie sua app1dependência (por exemplo ('app1', '0006...'),). Essa é a migração "imediatamente anterior" app1e deve incluir dependências em toda a lógica de criação de modelo real.
   • Abra app2.migrations.0004_auto_<date>e adicione a dependência que você acabou de copiar em sua dependencieslista.

Se você tem um ForeignKeyrelacionamento com o modelo que está movendo, o que foi dito acima pode não funcionar. Isso acontece porque:

• Dependências não são criadas automaticamente para as ForeignKeyalterações
• Como não queremos agrupar as ForeignKeyalterações state_operations, precisamos garantir que elas sejam separadas das operações da tabela.

NOTA: O Django 2.2 adicionou um aviso ( models.E028) que quebra esse método. Você pode contornar isso, managed=Falsemas eu não o testei.

O conjunto "mínimo" de operações difere dependendo da situação, mas o procedimento a seguir deve funcionar para a maioria / todas as ForeignKeymigrações:

1. COPIE o modelo de app1para app2, defina db_table, mas NÃO altere nenhuma referência FK.
2. Execute makemigrationse agrupe toda a app2migração state_operations(veja acima)
   • Como acima, adicione uma dependência na app2 CreateTableúltima app1migração
3. Aponte todas as referências FK para o novo modelo. Se você não estiver usando referências de seqüência de caracteres, mova o modelo antigo para a parte inferior de models.py(NÃO remova-o) para que ele não concorra com a classe importada.

4. Execute, makemigrationsmas NÃO envolva nada state_operations(as alterações do FK realmente devem acontecer). Adicione uma dependência em todas as ForeignKeymigrações (ou seja AlterField) à CreateTablemigração app2(você precisará desta lista para a próxima etapa, portanto, acompanhe-as). Por exemplo:

   • Encontre a migração que inclui, CreateModelpor exemplo, app2.migrations.0002_auto_<date>e copie o nome dessa migração.

   • Encontre todas as migrações que tenham uma ForeignKey para esse modelo (por exemplo, pesquisando app2.YourModelpara encontrar migrações como:

     class Migration(migrations.Migration):
     
         dependencies = [
             ('otherapp', '0001_initial'),
         ]
     
         operations = [
             migrations.AlterField(
                 model_name='relatedmodel',
                 name='fieldname',
                 field=models.ForeignKey(... to='app2.YourModel'),
             ),
         ]

   • Adicione a CreateModelmigração como uma dependência:

     class Migration(migrations.Migration):
     
         dependencies = [
             ('otherapp', '0001_initial'),
             ('app2', '0002_auto_<date>'),
         ]  

5. Remova os modelos de app1

6. Corre makemigrations e agrupe a app1migração state_operations.
   • Adicione uma dependência a todas as ForeignKeymigrações (ou seja,AlterField ) da etapa anterior (pode incluir migrações em app1e app2).
   • Quando eu criei essas migrações, elas DeleteTablejá dependiam das AlterFieldmigrações, então não precisei aplicá-las manualmente (ou seja, Alterantes Delete).

Neste ponto, o Django está pronto. O novo modelo aponta para a tabela antiga e as migrações do Django convenceram-na de que tudo foi realocado adequadamente. A grande ressalva (da resposta de @ Michael) é que um novoContentType é criado para o novo modelo. Se você vincular (por exemplo, por ForeignKey) a tipos de conteúdo, precisará criar uma migração para atualizar a ContentTypetabela.

Eu queria limpar depois de mim mesmo (opções Meta e nomes de tabelas), então usei o seguinte procedimento (do @Michael):

1. Remova o db_table entrada Meta
2. Corre makemigrations novamente para gerar a renomeação do banco de dados
3. Edite essa última migração e verifique se depende da DeleteTablemigração. Não parece que seja necessário, pois Deletedeve ser puramente lógico, mas cometer erros (por exemplo app1_yourmodel, não existe) se não existir.

Outra alternativa hacky, se os dados não forem grandes ou muito complicados, mas ainda importantes de manter, é:

• Obter acessórios de dados usando manage.py dumpdata
• Prossiga para modelar mudanças e migrações corretamente, sem relacionar as mudanças
• Global substitua os equipamentos dos nomes antigos de modelo e aplicativo pelos novos
• Carregar dados usando manage.py loaddata

Copiado da minha resposta em https://stackoverflow.com/a/47392970/8971048

Caso você precise mover o modelo e não tenha mais acesso ao aplicativo (ou não queira mais), crie uma nova Operação e considere criar um novo modelo apenas se o modelo migrado não existir.

Neste exemplo, estou passando 'MyModel' de old_app para myapp.

class MigrateOrCreateTable(migrations.CreateModel):
    def __init__(self, source_table, dst_table, *args, **kwargs):
        super(MigrateOrCreateTable, self).__init__(*args, **kwargs)
        self.source_table = source_table
        self.dst_table = dst_table

    def database_forwards(self, app_label, schema_editor, from_state, to_state):
        table_exists = self.source_table in schema_editor.connection.introspection.table_names()
        if table_exists:
            with schema_editor.connection.cursor() as cursor:
                cursor.execute("RENAME TABLE {} TO {};".format(self.source_table, self.dst_table))
        else:
            return super(MigrateOrCreateTable, self).database_forwards(app_label, schema_editor, from_state, to_state)


class Migration(migrations.Migration):

    dependencies = [
        ('myapp', '0002_some_migration'),
    ]

    operations = [
        MigrateOrCreateTable(
            source_table='old_app_mymodel',
            dst_table='myapp_mymodel',
            name='MyModel',
            fields=[
                ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
                ('name', models.CharField(max_length=18))
            ],
        ),
    ]

Isso é testado aproximadamente, portanto, não esqueça de fazer backup do seu banco de dados !!!

Por exemplo, existem dois aplicativos: src_appe dst_appqueremos mover o modelo MoveMede src_appparadst_app .

Crie migrações vazias para os dois aplicativos:

python manage.py makemigrations --empty src_app
python manage.py makemigrations --empty dst_app

Vamos supor que as novas migrações são XXX1_src_app_newe XXX1_dst_app_new, as principais migrações anteriores são XXX0_src_app_oldeXXX0_dst_app_old .

Adicione uma operação que renomeie a tabela para o MoveMemodelo e renomeie seu app_label no ProjectState para XXX1_dst_app_new. Não se esqueça de adicionar dependência à XXX0_src_app_oldmigração. A XXX1_dst_app_newmigração resultante é:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations

# this operations is almost the same as RenameModel
# https://github.com/django/django/blob/1.7/django/db/migrations/operations/models.py#L104
class MoveModelFromOtherApp(migrations.operations.base.Operation):

    def __init__(self, name, old_app_label):
        self.name = name
        self.old_app_label = old_app_label

    def state_forwards(self, app_label, state):

        # Get all of the related objects we need to repoint
        apps = state.render(skip_cache=True)
        model = apps.get_model(self.old_app_label, self.name)
        related_objects = model._meta.get_all_related_objects()
        related_m2m_objects = model._meta.get_all_related_many_to_many_objects()
        # Rename the model
        state.models[app_label, self.name.lower()] = state.models.pop(
            (self.old_app_label, self.name.lower())
        )
        state.models[app_label, self.name.lower()].app_label = app_label
        for model_state in state.models.values():
            try:
                i = model_state.bases.index("%s.%s" % (self.old_app_label, self.name.lower()))
                model_state.bases = model_state.bases[:i] + ("%s.%s" % (app_label, self.name.lower()),) + model_state.bases[i+1:]
            except ValueError:
                pass
        # Repoint the FKs and M2Ms pointing to us
        for related_object in (related_objects + related_m2m_objects):
            # Use the new related key for self referential related objects.
            if related_object.model == model:
                related_key = (app_label, self.name.lower())
            else:
                related_key = (
                    related_object.model._meta.app_label,
                    related_object.model._meta.object_name.lower(),
                )
            new_fields = []
            for name, field in state.models[related_key].fields:
                if name == related_object.field.name:
                    field = field.clone()
                    field.rel.to = "%s.%s" % (app_label, self.name)
                new_fields.append((name, field))
            state.models[related_key].fields = new_fields

    def database_forwards(self, app_label, schema_editor, from_state, to_state):
        old_apps = from_state.render()
        new_apps = to_state.render()
        old_model = old_apps.get_model(self.old_app_label, self.name)
        new_model = new_apps.get_model(app_label, self.name)
        if self.allowed_to_migrate(schema_editor.connection.alias, new_model):
            # Move the main table
            schema_editor.alter_db_table(
                new_model,
                old_model._meta.db_table,
                new_model._meta.db_table,
            )
            # Alter the fields pointing to us
            related_objects = old_model._meta.get_all_related_objects()
            related_m2m_objects = old_model._meta.get_all_related_many_to_many_objects()
            for related_object in (related_objects + related_m2m_objects):
                if related_object.model == old_model:
                    model = new_model
                    related_key = (app_label, self.name.lower())
                else:
                    model = related_object.model
                    related_key = (
                        related_object.model._meta.app_label,
                        related_object.model._meta.object_name.lower(),
                    )
                to_field = new_apps.get_model(
                    *related_key
                )._meta.get_field_by_name(related_object.field.name)[0]
                schema_editor.alter_field(
                    model,
                    related_object.field,
                    to_field,
                )

    def database_backwards(self, app_label, schema_editor, from_state, to_state):
        self.old_app_label, app_label = app_label, self.old_app_label
        self.database_forwards(app_label, schema_editor, from_state, to_state)
        app_label, self.old_app_label = self.old_app_label, app_label

    def describe(self):
        return "Move %s from %s" % (self.name, self.old_app_label)


class Migration(migrations.Migration):

    dependencies = [
       ('dst_app', 'XXX0_dst_app_old'),
       ('src_app', 'XXX0_src_app_old'),
    ]

    operations = [
        MoveModelFromOtherApp('MoveMe', 'src_app'),
    ]

Adicione dependência de XXX1_dst_app_newpara XXX1_src_app_new. XXX1_src_app_newé uma migração não operacional que é necessária para garantir que futuras src_appmigrações sejam executadas depois XXX1_dst_app_new.

Mover MoveMede src_app/models.pypara dst_app/models.py. Então corra:

python manage.py migrate

Isso é tudo!

Você pode tentar o seguinte (não testado):

1. mova o modelo de src_appparadest_app
2. migrar dest_app; verifique se a migração do esquema depende da src_appmigração mais recente ( https://docs.djangoproject.com/en/dev/topics/migrations/#migration-files )
3. adicionar uma migração de dados para dest_app, que copia todos os dados desrc_app
4. migrar src_app; verifique se a migração do esquema depende da migração mais recente (dados) de dest_app- ou seja: a migração da etapa 3

Observe que você copiará a tabela inteira, em vez de movê- la, mas dessa maneira os dois aplicativos não precisam tocar em uma tabela que pertence ao outro aplicativo, o que eu acho mais importante.

Digamos que você esteja movendo o modelo TheModel de app_a para app_b.

Uma solução alternativa é alterar as migrações existentes manualmente. A ideia é que sempre que você vir uma operação alterando o TheModel nas migrações do app_a, copie essa operação para o final da migração inicial do app_b. E cada vez que você vê uma referência 'app_a.TheModel' nas migrações de app_a, você a altera para 'app_b.TheModel'.

Acabei de fazer isso em um projeto existente, onde queria extrair um determinado modelo para um aplicativo reutilizável. O procedimento correu bem. Eu acho que as coisas seriam muito mais difíceis se houvesse referências de app_b para app_a. Além disso, eu tinha um Meta.db_table definido manualmente para o meu modelo, o que poderia ter ajudado.

Notavelmente, você terá um histórico de migração alterado. Isso não importa, mesmo se você tiver um banco de dados com as migrações originais aplicadas. Se as migrações original e reescrita terminarem com o mesmo esquema de banco de dados, essa reescrita deverá estar OK.

1. altere os nomes dos modelos antigos para 'model_name_old'
2. migrações
3. crie novos modelos chamados 'model_name_new' com relacionamentos idênticos nos modelos relacionados (por exemplo, o modelo do usuário agora possui user.blog_old e user.blog_new)
4. migrações
5. escreva uma migração customizada que migra todos os dados para as novas tabelas de modelo
6. teste essas migrações, comparando backups com novas cópias de banco de dados antes e depois da execução das migrações
7. quando tudo estiver satisfatório, exclua os modelos antigos
8. migrações
9. altere os novos modelos para o nome correto 'model_name_new' -> 'model_name'
10. testar toda a enorme quantidade de migrações em um servidor intermediário
11. desligue o site de produção por alguns minutos para executar todas as migrações sem que os usuários interfiram

Faça isso individualmente para cada modelo que precisa ser movido. Eu não sugeriria fazer o que a outra resposta diz mudando para números inteiros e retornando para chaves estrangeiras. Há uma chance de que novas chaves estrangeiras sejam diferentes e linhas possam ter IDs diferentes após as migrações e eu não queria correr nenhum risco de IDs incompatíveis ao voltar para chaves estrangeiras.