Como migrar um modelo de um aplicativo django para um novo?

Eu tenho um aplicativo django com quatro modelos. Percebo agora que um desses modelos deve estar em um aplicativo separado. Eu tenho o sul instalado para migrações, mas não acho que isso possa ser feito automaticamente. Como posso migrar um dos modelos do aplicativo antigo para um novo?

Além disso, lembre-se de que vou precisar que este seja um processo repetitivo, para que eu possa migrar o sistema de produção e tal.

Como migrar usando o sul.

Digamos que temos dois aplicativos: comuns e específicos:

myproject/
|-- common
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   `-- 0002_create_cat.py
|   `-- models.py
`-- specific
    |-- migrations
    |   |-- 0001_initial.py
    |   `-- 0002_create_dog.py
    `-- models.py

Agora, queremos mover o modelo common.models.cat para um aplicativo específico (precisamente para specific.models.cat). Primeiro faça as alterações no código fonte e depois execute:

$ python manage.py schemamigration specific create_cat --auto
 + Added model 'specific.cat'
$ python manage.py schemamigration common drop_cat --auto
 - Deleted model 'common.cat'

myproject/
|-- common
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   |-- 0002_create_cat.py
|   |   `-- 0003_drop_cat.py
|   `-- models.py
`-- specific
    |-- migrations
    |   |-- 0001_initial.py
    |   |-- 0002_create_dog.py
    |   `-- 0003_create_cat.py
    `-- models.py

Agora precisamos editar os dois arquivos de migração:

#0003_create_cat: replace existing forward and backward code
#to use just one sentence:

def forwards(self, orm):
    db.rename_table('common_cat', 'specific_cat') 

    if not db.dry_run:
        # For permissions to work properly after migrating
        orm['contenttypes.contenttype'].objects.filter(
            app_label='common',
            model='cat',
        ).update(app_label='specific')

def backwards(self, orm):
    db.rename_table('specific_cat', 'common_cat')

    if not db.dry_run:
        # For permissions to work properly after migrating
        orm['contenttypes.contenttype'].objects.filter(
            app_label='specific',
            model='cat',
        ).update(app_label='common')

#0003_drop_cat:replace existing forward and backward code
#to use just one sentence; add dependency:

depends_on = (
    ('specific', '0003_create_cat'),
)
def forwards(self, orm):
    pass
def backwards(self, orm):
    pass

Agora, as duas migrações de aplicativos estão cientes da mudança e a vida é um pouco menos :-) Definir esse relacionamento entre migrações é a chave do sucesso. Agora, se você fizer:

python manage.py migrate common
 > specific: 0003_create_cat
 > common: 0003_drop_cat

fará a migração e

python manage.py migrate specific 0002_create_dog
 < common: 0003_drop_cat
 < specific: 0003_create_cat

migrará as coisas para baixo.

Observe que, para a atualização do esquema, usei o aplicativo comum e, para o downgrade, usei o aplicativo específico. Isso ocorre porque a dependência aqui funciona.

Para construir sobre potr Czachur 's resposta , situações que envolvem ForeignKeys são mais complicado e deve ser tratado de forma ligeiramente diferente.

(O exemplo a seguir se baseia nos aplicativos commone specificmencionados na resposta atual).

# common/models.py

class Cat(models.Model):
    # ...

class Toy(models.Model):
    belongs_to = models.ForeignKey(Cat)
    # ...

mudaria para

# common/models.py

from specific.models import Cat

class Toy(models.Model):
    belongs_to = models.ForeignKey(Cat)
    # ...

# specific/models.py

class Cat(models.Model):
    # ...

Corrida

./manage.py schemamigration common --auto
./manage.py schemamigration specific --auto # or --initial

geraria as seguintes migrações (estou intencionalmente ignorando as alterações do Django ContentType - consulte a resposta mencionada anteriormente para saber como lidar com isso):

# common/migrations/0009_auto__del_cat.py

class Migration(SchemaMigration):
    def forwards(self, orm):
        db.delete_table('common_cat')
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['specific.Cat']))

    def backwards(self, orm):
        db.create_table('common_cat', (
            # ...
        ))
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['common.Cat']))

# specific/migrations/0004_auto__add_cat.py

class Migration(SchemaMigration):
    def forwards(self, orm):
        db.create_table('specific_cat', (
            # ...
        ))

    def backwards(self, orm):
        db.delete_table('specific_cat')

Como você pode ver, o FK deve ser alterado para fazer referência à nova tabela. Precisamos adicionar uma dependência para que saibamos a ordem em que as migrações serão aplicadas (e, assim, que a tabela existirá antes de tentarmos adicionar um FK a ela), mas também precisamos garantir que a rolagem para trás funcione também porque o dependência se aplica na direção inversa .

# common/migrations/0009_auto__del_cat.py

class Migration(SchemaMigration):

    depends_on = (
        ('specific', '0004_auto__add_cat'),
    )

    def forwards(self, orm):
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['specific.Cat']))

    def backwards(self, orm):
        db.rename_table('specific_cat', 'common_cat')
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['common.Cat']))

# specific/migrations/0004_auto__add_cat.py

class Migration(SchemaMigration):
    def forwards(self, orm):
        db.rename_table('common_cat', 'specific_cat')

    def backwards(self, orm):
        pass

De acordo com a documentação do Sul , depends_ongarantirá que seja 0004_auto__add_catexecutado antes 0009_auto__del_cat ao migrar para a frente, mas na ordem oposta ao migrar para trás . Se deixássemos db.rename_table('specific_cat', 'common_cat')na specificreversão, a commonreversão falharia ao tentar migrar a ForeignKey porque a tabela mencionada na tabela não existiria.

Espero que isso esteja mais próximo de uma situação do "mundo real" do que as soluções existentes e alguém ache isso útil. Felicidades!

Os modelos não são muito acoplados aos aplicativos, portanto, a movimentação é bastante simples. O Django usa o nome do aplicativo no nome da tabela do banco de dados, portanto, se você deseja mover o aplicativo, pode renomear a tabela do banco de dados por meio de uma ALTER TABLEinstrução SQL ou, ainda mais simples, basta usar o db_tableparâmetro na Metaclasse do seu modelo para consultar a Antigo nome.

Se você já usou ContentTypes ou relações genéricas em qualquer lugar do seu código até agora, provavelmente desejará renomear o app_label do contenttype apontando para o modelo que está sendo movido, para que as relações existentes sejam preservadas.

Obviamente, se você não tem nenhum dado a preservar, a coisa mais fácil a fazer é eliminar completamente as tabelas do banco de dados e executar ./manage.py syncdbnovamente.

Aqui está mais uma correção para a excelente solução da Potr. Adicione o seguinte a specific / 0003_create_cat

depends_on = (
    ('common', '0002_create_cat'),
)

A menos que essa dependência seja definida, o Sul não garantirá que a common_cattabela exista no momento em que específico / 0003_create_cat for executado, lançando um django.db.utils.OperationalError: no such table: common_caterro em você.

O sul executa migrações em ordem lexicográfica, a menos que a dependência seja explicitamente definida. Como commonvem antes de specifictodas as commonmigrações serem executadas antes da renomeação da tabela, provavelmente não seria reproduzido no exemplo original mostrado pelo Potr. Mas se você renomear commonpara app2e specificpara app1você, encontrará esse problema.

O processo em que eu decidi desde que voltei aqui algumas vezes e decidi formalizá-lo.

Esta foi originalmente construída sobre a resposta de potr Czachur e resposta de Matt Briançon , usando 0.8.4 do Sul

Etapa 1. Descubra relacionamentos de chave estrangeira filho

# Caution: This finds OneToOneField and ForeignKey.
# I don't know if this finds all the ways of specifying ManyToManyField.
# Hopefully Django or South throw errors if you have a situation like that.
>>> Cat._meta.get_all_related_objects()
[<RelatedObject: common:toy related to cat>,
 <RelatedObject: identity:microchip related to cat>]

Portanto, neste caso estendido, descobrimos outro modelo relacionado como:

# Inside the "identity" app...
class Microchip(models.Model):

    # In reality we'd probably want a ForeignKey, but to show the OneToOneField
    identifies = models.OneToOneField(Cat)

    ...

Etapa 2. Crie migrações

# Create the "new"-ly renamed model
# Yes I'm changing the model name in my refactoring too.
python manage.py schemamigration specific create_kittycat --auto

# Drop the old model
python manage.py schemamigration common drop_cat --auto

# Update downstream apps, so South thinks their ForeignKey(s) are correct.
# Can skip models like Toy if the app is already covered
python manage.py schemamigration identity update_microchip_fk --auto

Etapa 3. Controle de origem: confirme as alterações até o momento.

Torna o processo mais repetitivo se você tiver conflitos de mesclagem, como colegas de equipe que escrevem migrações nos aplicativos atualizados.

Etapa 4. Adicione dependências entre as migrações.

Basicamente, create_kittycatdepende do estado atual de tudo, e tudo depende create_kittycat.

# create_kittycat
class Migration(SchemaMigration):

    depends_on = (
        # Original model location
        ('common', 'the_one_before_drop_cat'),

        # Foreign keys to models not in original location
        ('identity', 'the_one_before_update_microchip_fk'),
    )
    ...


# drop_cat
class Migration(SchemaMigration):

    depends_on = (
        ('specific', 'create_kittycat'),
    )
    ...


# update_microchip_fk
class Migration(SchemaMigration):

    depends_on = (
        ('specific', 'create_kittycat'),
    )
    ...

Etapa 5. A tabela renomeia a alteração que queremos fazer.

# create_kittycat
class Migration(SchemaMigration):

    ...

    # Hopefully for create_kittycat you only need to change the following
    # 4 strings to go forward cleanly... backwards will need a bit more work.
    old_app = 'common'
    old_model = 'cat'
    new_app = 'specific'
    new_model = 'kittycat'

    # You may also wish to update the ContentType.name,
    # personally, I don't know what its for and
    # haven't seen any side effects from skipping it.

    def forwards(self, orm):

        db.rename_table(
            '%s_%s' % (self.old_app, self.old_model),
            '%s_%s' % (self.new_app, self.new_model),
        )

        if not db.dry_run:
            # For permissions, GenericForeignKeys, etc to work properly after migrating.
            orm['contenttypes.contenttype'].objects.filter(
                app_label=self.old_app,
                model=self.old_model,
            ).update(
                app_label=self.new_app,
                model=self.new_model,
            )

        # Going forwards, should be no problem just updating child foreign keys
        # with the --auto in the other new South migrations

    def backwards(self, orm):

        db.rename_table(
            '%s_%s' % (self.new_app, self.new_model),
            '%s_%s' % (self.old_app, self.old_model),
        )

        if not db.dry_run:
            # For permissions, GenericForeignKeys, etc to work properly after migrating.
            orm['contenttypes.contenttype'].objects.filter(
                app_label=self.new_app,
                model=self.new_model,
            ).update(
                app_label=self.old_app,
                model=self.old_model,
            )

        # Going backwards, you probably should copy the ForeignKey
        # db.alter_column() changes from the other new migrations in here
        # so they run in the correct order.
        #
        # Test it! See Step 6 for more details if you need to go backwards.
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['common.Cat']))
        db.alter_column('identity_microchip', 'identifies_id', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['common.Cat']))


# drop_cat
class Migration(SchemaMigration):

    ...

    def forwards(self, orm):
        # Remove the db.delete_table(), if you don't at Step 7 you'll likely get
        # "django.db.utils.ProgrammingError: table "common_cat" does not exist"

        # Leave existing db.alter_column() statements here
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['specific.KittyCat']))

    def backwards(self, orm):
        # Copy/paste the auto-generated db.alter_column()
        # into the create_kittycat migration if you need backwards to work.
        pass


# update_microchip_fk
class Migration(SchemaMigration):

    ...

    def forwards(self, orm):
        # Leave existing db.alter_column() statements here
        db.alter_column('identity_microchip', 'identifies_id', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['specific.KittyCat']))

    def backwards(self, orm):
        # Copy/paste the auto-generated db.alter_column()
        # into the create_kittycat migration if you need backwards to work.
        pass

Etapa 6. Somente se você precisar que o backwards () funcione E faça com que o KeyError seja executado ao contrário.

# the_one_before_create_kittycat
class Migration(SchemaMigration):

    # You many also need to add more models to South's FakeORM if you run into
    # more KeyErrors, the trade-off chosen was to make going forward as easy as
    # possible, as that's what you'll probably want to do once in QA and once in
    # production, rather than running the following many times:
    #
    # python manage.py migrate specific <the_one_before_create_kittycat>

    models = {
        ...
        # Copied from 'identity' app, 'update_microchip_fk' migration
        u'identity.microchip': {
            'Meta': {'object_name': 'Microchip'},
            u'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}),
            'name': ('django.db.models.fields.CharField', [], {'unique': 'True', 'max_length': '80'}),
            'identifies': ('django.db.models.fields.related.OneToOneField', [], {to=orm['specific.KittyCat']})
        },
        ...
    }

Etapa 7. Teste - o que funciona para mim pode não ser suficiente para a sua situação na vida real :)

python manage.py migrate

# If you need backwards to work
python manage.py migrate specific <the_one_before_create_kittycat>

Portanto, usar a resposta original do @Potr acima não funcionou para mim no Sul 0.8.1 e no Django 1.5.1. Estou publicando o que funcionou para mim abaixo, na esperança de que seja útil para outras pessoas.

from south.db import db
from south.v2 import SchemaMigration
from django.db import models

class Migration(SchemaMigration):

    def forwards(self, orm):
        db.rename_table('common_cat', 'specific_cat') 

        if not db.dry_run:
             db.execute(
                "update django_content_type set app_label = 'specific' where "
                " app_label = 'common' and model = 'cat';")

    def backwards(self, orm):
        db.rename_table('specific_cat', 'common_cat')
            db.execute(
                "update django_content_type set app_label = 'common' where "
                " app_label = 'specific' and model = 'cat';")

Vou dar uma versão mais explícita de uma das coisas que Daniel Roseman sugeriu em sua resposta ...

Se você acabou de alterar o db_tableatributo Meta do modelo, você mudou para apontar para o nome da tabela existente (em vez do novo nome que o Django daria se você soltasse e fizesse umsyncdb ), então você pode evitar migrações sul complicadas. por exemplo:

Original:

# app1/models.py
class MyModel(models.Model):
    ...

Depois de se mudar:

# app2/models.py
class MyModel(models.Model):
    class Meta:
        db_table = "app1_mymodel"

Agora você só precisa fazer uma migração de dados para atualizar o app_labelparaMyModel na django_content_typetabela e deve estar pronto ...

Execute ./manage.py datamigration django update_content_typee edite o arquivo que South cria para você:

def forwards(self, orm):
    moved = orm.ContentType.objects.get(app_label='app1', model='mymodel')
    moved.app_label = 'app2'
    moved.save()

def backwards(self, orm):
    moved = orm.ContentType.objects.get(app_label='app2', model='mymodel')
    moved.app_label = 'app1'
    moved.save()