Cómo mover un modelo entre dos aplicaciones Django (Django 1.7)

Esto se puede hacer con bastante facilidad usando migrations.SeparateDatabaseAndState. Básicamente, usamos una operación de base de datos para cambiar el nombre de la tabla simultáneamente con dos operaciones de estado para eliminar el modelo del historial de una aplicación y crearlo en el de otra.

Eliminar de la aplicación antigua

python manage.py makemigrations old_app --empty

En la migración:

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)
    ]

Añadir a la nueva aplicación

Primero, copie el modelo a la nueva aplicación model.py, entonces:

python manage.py makemigrations new_app

Esto generará una migración con una operación ingenua CreateModel como única operación. Envuelva eso en una operación SeparateDatabaseAndState tal que no intentemos recrear la tabla. También incluya la migración previa como una dependencia:

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)
    ]

Me encontré con el mismo problema. La respuesta de Ozan me ayudó mucho, pero desafortunadamente no fue suficiente. De hecho, tenía varios enlaces ForeignKey al modelo que quería mover. Después de un dolor de cabeza encontré la solución, así que decidí publicarla para resolver el tiempo de la gente.

Necesitas 2 pasos más:

1. Antes de hacer nada, cambia todos tus ForeignKey enlaces a TheModel a Integerfield. A continuación, ejecute python manage.py makemigrations
2. Después de hacer los pasos de Ozan, vuelve a convertir tus claves foráneas: put back ForeignKey(TheModel)en lugar de IntegerField(). Luego haga las migraciones de nuevo (python manage.py makemigrations). Luego puede migrar y debería funcionar (python manage.py migrate)

Espero que ayude. Por supuesto, pruébelo en local antes de probar en producción para evitar malas sorpresas:)

Cómo lo hice (probado en Django==1.8, con postgres, así que probablemente también 1.7)

Situación

App1.YourModel

Pero quieres que vaya a: app2.YourModel

1. Copia tu modelo (el código) de app1 a app2.

2. Añadir esto a app2.YourModel:

   Class Meta:
       db_table = 'app1_yourmodel'
   

3. $ python manage.py makemigrations app2

4. Una nueva migración (p.ej. 0009_auto_something.py) se realiza en app2 con una migración.Modelo de creación() instrucción, mueva esta instrucción a la migración inicial de app2 (p. ej. 0001_initial.py) (será como siempre ha estado allí). Y ahora eliminar la migración creada = 0009_auto_something.py

5. Así como actúas, como app2.YourModel siempre ha estado ahí, ahora elimina la existencia de app1.YourModel de tus migraciones. Significado: comenta las sentencias CreateModel, y cada ajuste o migración de datos que usaste después de eso.

6. Y por supuesto, cada referencia a app1.YourModel tiene que ser cambiado a app2.YourModel a través de su proyecto. Además, no olvide que todas las claves foráneas posibles para app1.Tu modelo en las migraciones tiene que ser cambiado a app2.YourModel

7. Ahora si lo haces python python manage.py migrar, nada ha cambiado, también cuando lo haces python python manage.py makemigrations, no se ha detectado nada nuevo.

8. Ahora el toque final: eliminar la Meta de Clase de app2.YourModel y hacer python python manage.py makemigrations app2 y python manage.py migrar app2 (si miras esta migración verás algo como esto:)

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

Table=None, significa que tomará el nombre de tabla predeterminado, que en este caso será app2_yourmodel.

1. HECHO, con los datos guardados.

P. S durante la migración verá que content_type app1.yourmodel ha sido eliminado y puede ser eliminado. Puedes decir que sí, pero solo si no lo usas. En caso de que pesadamente confíe en que FKs a ese tipo de contenido esté intacto, no responda sí o no todavía, pero vaya a la base de datos esa vez manualmente y elimine la aplicación contentype 2.yourmodel, y cambiar el nombre de la aplicación contenttype 1.yourmodel to app2.yourmodel, y luego continuar contestando no.

Recibo migraciones nerviosas de codificación manual (como lo requiere la respuesta de Ozan), por lo que lo siguiente combina las estrategias de Ozan y Michael para minimizar la cantidad de codificación manual requerida:{[79]]}

1. Antes de mover cualquier modelo, asegúrese de que está trabajando con una línea de base limpia ejecutando makemigrations.
2. Mueva el código para el Modelo de app1 a app2

3. Como recomienda @Michael, apuntamos el nuevo modelo a la antigua tabla de la base de datos usando el Meta db_table opción en el modelo" nuevo":

   class Meta:
       db_table = 'app1_yourmodel'
   

4. Ejecutar makemigrations. Esto generará CreateModel en app2 y {[12] {} en[6]}. Técnicamente, estas migraciones se refieren a la misma tabla y eliminarían (incluidos todos los datos) y volverían a crear la tabla.

5. En realidad, no queremos (o necesitamos) hacer nada a la mesa. Solo necesitamos que Django crea que el cambio se ha hecho. Según la respuesta de @Ozan, la bandera state_operations en SeparateDatabaseAndState hace esto. Así que envolvemos todo el migrations entradas EN AMBOS ARCHIVOS DE MIGRACIÓN con SeparateDatabaseAndState(state_operations=[...]). Por ejemplo,

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

   Se convierte en

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

6. EDITAR : También debe asegurarse de que la nueva migración "virtual" CreateModel depende de cualquier migración que realmente haya creado o alterado la tabla original. Por ejemplo, si su nuevo migraciones son app2.migrations.0004_auto_<date> (para el Create) y app1.migrations.0007_auto_<date> (para el Delete), lo más sencillo es:

   • Abra app1.migrations.0007_auto_<date> y copie su dependencia app1 (e. g. ('app1', '0006...'),). Esta es la migración" inmediatamente anterior " en app1 y debe incluir dependencias en toda la lógica de construcción del modelo real.
   • Abre app2.migrations.0004_auto_<date> y añade la dependencia que acabas de copiar a su lista dependencies.

EDITAR: Si tiene ForeignKey relación(es) con el modelo que está moviendo, lo anterior puede no funcionar. Esto sucede porque:

• Las dependencias no se crean automáticamente para los cambios ForeignKey
• no queremos para envolver los cambios ForeignKey en state_operations, debemos asegurarnos de que estén separados de las operaciones de la tabla.

El conjunto "mínimo" de operaciones difiere dependiendo de la situación, pero el siguiente procedimiento debería funcionar para la mayoría/todas las migraciones ForeignKey:

1. COPIE el modelo de app1 a app2, establezca db_table, pero NO cambie ninguna referencia FK.
2. Ejecute makemigrations y envuelva toda la migración app2 en state_operations (ver arriba)
   • Como anteriormente, agregue una dependencia en el app2 CreateTable a la última app1 migración
3. Apunta todas las referencias FK al nuevo modelo. Si no está utilizando referencias de cadena, mueva el modelo antiguo a la parte inferior de models.py (NO lo elimine) para que no compita con la clase importada.

4. Ejecute makemigrations pero NO envuelva nada en state_operations (los cambios FK realmente deberían ocurrir)

   • Agregue una dependencia en todas las migraciones ForeignKey (es decir, AlterField) a la migración CreateTable en app2 (usted necesita esta lista para el siguiente paso, así que haga un seguimiento de ellos). Por ejemplo:
   • Busque la migración que incluye el CreateModel por ejemplo, app2.migrations.0002_auto_<date> y copie el nombre de esa migración.

   • Encuentra todas las migraciones que tienen una ForeignKey para ese modelo (por ejemplo, buscando app2.YourModel para encontrar migraciones como:

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

   • Agregue la migración CreateModel como como una dependencia:

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

5. Eliminar los modelos de app1

6. Ejecutar makemigrations y envolver el app1 migración en state_operations.
   • Agregue una dependencia a todas las migraciones ForeignKey (es decir, AlterField) del paso anterior (puede incluir migraciones en app1 y app2).
   • Cuando construí estas migraciones, DeleteTable ya dependía de las migraciones AlterField, por lo que no necesitaba forzarlas manualmente (es decir, Alter antes de Delete).

En este punto, Django está listo. El nuevo modelo apunta a la vieja tabla y las migraciones de Django lo han convencido de que todo ha sido reubicado apropiadamente. La gran advertencia (de la respuesta de @Michael) es que se crea un nuevo ContentType para el nuevo modelo. Si enlazas (por ejemplo, por ForeignKey) a tipos de contenido, necesitarás crear una migración para actualizar la tabla ContentType.

Quería limpiar después de mí mismo (opciones Meta y nombres de tabla), así que usé el siguiente procedimiento (de @Michael):

1. Eliminar la entrada db_table Meta
2. Ejecute makemigrations de nuevo para generar la base de datos rename
3. Edite esta última migración y asegúrese de que depende de la migración DeleteTable. No parece que deba ser necesario ya que el Delete debería ser puramente lógico, pero me he encontrado con errores (por ejemplo, app1_yourmodel no existe) si no lo hago.

Esto se prueba aproximadamente, así que no se olvide de copia de seguridad de su base de datos!!!

Por ejemplo, hay dos aplicaciones: src_app y dst_app, queremos mover el modelo MoveMe de src_app a dst_app.

Crear migraciones vacías para ambas aplicaciones:

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

Supongamos que las nuevas migraciones son XXX1_src_app_new y XXX1_dst_app_new, las migraciones anteriores son XXX0_src_app_old y XXX0_dst_app_old.

Agrega una operación que cambia el nombre de table para MoveMe model y cambia el nombre de app_label en ProjectState a XXX1_dst_app_new. No olvide agregar dependencia en la migración XXX0_src_app_old. La migración resultante XXX1_dst_app_new es:

# -*- 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'),
    ]

Añade dependencia de XXX1_dst_app_new a XXX1_src_app_new. XXX1_src_app_new es la migración sin op que se necesita para asegurarse de que las futuras migraciones src_app se ejecutarán después de XXX1_dst_app_new.

Mover MoveMe de src_app/models.py a dst_app/models.py. A continuación, ejecutar:

python manage.py migrate

Eso es todo!

Puedes probar lo siguiente (no probado):

1. mueva el modelo de src_app a dest_app
2. migrate dest_app; asegúrese de que la migración del esquema depende de la última migración src_app ( https://docs.djangoproject.com/en/dev/topics/migrations/#migration-files )
3. agregue una migración de datos a dest_app, que copie todos los datos de src_app
4. migrate src_app; asegúrese de que la migración del esquema depende de la última migración (de datos) de dest_app that es decir: la migración de step 3

Tenga en cuenta que será copiandotoda la tabla, en lugar de moviéndola, pero de esa manera ambas aplicaciones no tienen que tocar una tabla que pertenece a la otra aplicación, lo que creo que es más importante.

Digamos que está moviendo el modelo del modelo de app_a a app_b.

Una solución alternativa es alterar las migraciones existentes a mano. La idea es que cada vez que vea una operación alterando el modelo en las migraciones de app_a, copie esa operación al final de la migración inicial de app_b. Y cada vez que vea una referencia 'app_a.TheModel' en app_a migraciones, la cambia a 'app_b.TheModel'.

Acabo de hacer esto para un proyecto existente, donde quería extraer un cierto modele a una aplicación reutilizable. El procedimiento fue sin problemas. Supongo que las cosas serían mucho más difíciles si hubiera referencias de app_b a app_a. Además, tenía un Meta definido manualmente.db_table para mi modelo que podría haber ayudado.

Notablemente, terminará con un historial de migración alterado. Esto no importa, incluso si tiene una base de datos con las migraciones originales aplicadas. Si las migraciones original y reescrita terminan con el mismo esquema de base de datos, entonces dicha reescritura debe ser OK.

1. cambie los nombres de los modelos antiguos a'model_name_old'
2. makemigrations
3. hacer nuevos modelos llamados 'model_name_new' con relaciones idénticas en los modelos relacionados (eg. el modelo de usuario ahora tiene usuario.blog_old y usuario.blog_new)
4. makemigrations
5. escriba una migración personalizada que migre todos los datos a las tablas del nuevo modelo
6. pruebe el infierno de estas migraciones comparando copias de seguridad con nuevas copias de base de datos antes y después de ejecutar el migraciones
7. cuando todo sea satisfactorio, elimine los modelos antiguos
8. makemigrations
9. cambie los nuevos modelos al nombre correcto 'model_name_new' - > 'model_name'
10. pruebe toda la serie de migraciones en un servidor provisional
11. desconecte su sitio de producción durante unos minutos para ejecutar todas las migraciones sin que los usuarios interfieran

Haga esto individualmente para cada modelo que necesita ser movido. No sugeriría hacer lo que la otra respuesta dice por cambiar a enteros y volver a claves foráneas Existe la posibilidad de que las nuevas claves foráneas sean diferentes y las filas puedan tener diferentes ID después de las migraciones y no quería correr ningún riesgo de que no coincidan los ID al cambiar de nuevo a las claves foráneas.

Otra alternativa de hackeo si los datos no son grandes o demasiado complicados, pero aún así importantes de mantener, es:

• Obtenga los accesorios de datos usando manage.py dumpdata
• Proceda correctamente a los cambios y migraciones del modelo, sin relacionar los cambios
• Global reemplace los accesorios del modelo antiguo y los nombres de las aplicaciones por los nuevos
• Cargar datos usando manage.py loaddata

Copiado de mi respuesta en https://stackoverflow.com/a/47392970/8971048

En caso de que necesite mover el modelo y ya no tenga acceso a la aplicación (o no desee el acceso), puede crear una nueva operación y considerar crear un nuevo modelo solo si el modelo migrado no existe.

En este ejemplo estoy pasando 'MyModel' de old_app a 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))
            ],
        ),
    ]