Este documento explica como estruturar e a escrever migrações de banco de dados para diferentes cenários que você talvez encontre.
\nQuando isar múltimplos bancos de dados, você talvez precisse entender onde rodar e onde não rodar migrações para um banco de dados em partiular. Por exemplo, você talvez queira somente rodar migrações para um banco de dados em particular.
\nPara fazer isso você pode verificar o alias da conexão com o banco de dados dentro de uma operação RunPython olhando no attributo schema_editor.connection.alias:
from django.db import migrations\n\ndef forwards(apps, schema_editor):\n if not schema_editor.connection.alias == 'default':\n return\n # Your migration code goes here\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n # Dependencies to other migrations\n ]\n\n operations = [\n migrations.RunPython(forwards),\n ]\nVocê pode fornecer dicas que serão passadas para o método allow_migrate() do roteador de banco de dados como **hints:
myapp/dbrouters.pyclass MyRouter(object):\n\n def allow_migrate(self, db, app_label, model_name=None, **hints):\n if 'target_db' in hints:\n return db == hints['target_db']\n return True\nEntão para aproveitar isso em suas migrações, faça o seguinte:
\nfrom django.db import migrations\n\ndef forwards(apps, schema_editor):\n # Your migration code goes here\n ...\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n # Dependencies to other migrations\n ]\n\n operations = [\n migrations.RunPython(forwards, hints={'target_db': 'default'}),\n ]\nSe você executar RunPython ou RunSQL as operações só irão afetar um modelo, e isso é uma boa passar model_name como uma dica para que fique tão tranaprente quanto possível para o roteador. Isso é especialmente importante para reutilização e applicações de terceiros.
Aplicar uma migração “sem customizações” que adicione um campo não nulo e “unique” a uma table com registros existentes irá emitir um erro porque o valor usado para popular os registros existente é gerado somente uma vez, então quebrando o “contraint” “unique”.
\nPortanto, os seguintes passos devem ser seguidos. Neste exemplo, nós iremos adicionar um UUIDField não-nulo com um valor padrão. Modifique o campo respectivo de acordo com suas necessidades.
Adicione o campo no seu modelo com default=uuid.uuid4 e argumentos unique=True (escolha um padrão apropriado para o tipo de campor que você está adicionando).
Execute o comando makemigrations . Isso deve gerar uma migração com uma operação AddField.
Gera dois arquivos de migrações vazios para a mesma aplicação rodando makemigrations myapp --empty duas vezes. Renomeamos os arquivos de migração para dara eles nomes significativos nos exemplos abaixo
Copie a operação AddField da migração gerada automaticamente (o primeiro dos três novos arquivos) para a última migração e altere AddFiled para AlterField. Por exemplo:
0006_remove_uuid_null.py# -*- coding: utf-8 -*-\n# Generated by Django A.B on YYYY-MM-DD HH:MM\nfrom __future__ import unicode_literals\n\nfrom django.db import migrations, models\nimport uuid\n\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n ('myapp', '0005_populate_uuid_values'),\n ]\n\n operations = [\n migrations.AlterField(\n model_name='mymodel',\n name='uuid',\n field=models.UUIDField(default=uuid.uuid4, unique=True),\n ),\n ]\nEdite o primeiro arquivo da migração. A classe de migração gerada deve se parecer com isso:
\n0004_add_uuid_field.pyclass Migration(migrations.Migration):\n\n dependencies = [\n ('myapp', '0003_auto_20150129_1705'),\n ]\n\n operations = [\n migrations.AddField(\n model_name='mymodel',\n name='uuid',\n field=models.UUIDField(default=uuid.uuid4, unique=True),\n ),\n ]\nMude unique=True para null=True – isso irá criar o campo nullo imtermediário e adiar a criação da restrição “unique” até que tenhamos populado os valores únicos em todas os registros.
No primeiro arquivo de migração vazio, adicione um RunPython ou uma operaçãoi RunSQL para gerar os valores únicos(UUID no exemplo) para cada registro existente. Por exemplo:
0005_populate_uuid_values.py# -*- coding: utf-8 -*-\n# Generated by Django A.B on YYYY-MM-DD HH:MM\nfrom __future__ import unicode_literals\n\nfrom django.db import migrations, models\nimport uuid\n\ndef gen_uuid(apps, schema_editor):\n MyModel = apps.get_model('myapp', 'MyModel')\n for row in MyModel.objects.all():\n row.uuid = uuid.uuid4()\n row.save()\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n ('myapp', '0004_add_uuid_field'),\n ]\n\n operations = [\n # omit reverse_code=... if you don't want the migration to be reversible.\n migrations.RunPython(gen_uuid, reverse_code=migrations.RunPython.noop),\n ]\nAgora você pode aplicar as migrações como de costume com o comando migrate.
Note que há uma condição de concorrência se você deixar com que objetos sejam criados enquanto essa migração está rodando. Objetos criados depois do AddField``e antes do ``RunPython terão seus uuid’s sobrescritos.
django determina a ordem em que as migrações não devem ser aplicadas pelo nome do arquivo de cada migração, mas através da construção de um gráfico usando duas propriedade na classe Migration: dependencies e run_before.
se você estiver usando o comando makemigration você provavelmente já viu dependencies em ação por causa da migration auto-criada, tendo esta definição como parte do processo de criação.
A propridade dependencies está declarada como isto:
from django.db import migrations\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n ('myapp', '0123_the_previous_migration'),\n ]\nNormalmente isso é o bastante, mas de vez enquando você pode assegurar que sua migração rode antes de outras migrações. Isso é útil, por exemplo, para fazer migrações de aplicações de terceiros rodar depois de substituir seu AUTH_USER_MODEL.
Para conseguir isso, coloque todas as migrações que devem depender das suas no atributo run_before na sua classe Migration:
class Migration(migrations.Migration):\n ...\n\n run_before = [\n ('third_party_app', '0001_do_awesome'),\n ]\nPrefira usar dependencies ao run_before quando possível. Você deve somente usar o run_before se ele não é desejável ou impraticável para especificar dependencies na migração qual você quer rodar depois da que está escrevendo.
You can use a data migration to move data from one third-party application to\nanother.
\nIf you plan to remove the old app later, you’ll need to set the dependencies\nproperty based on whether or not the old app is installed. Otherwise, you’ll\nhave missing dependencies once you uninstall the old app. Similarly, you’ll\nneed to catch LookupError in the apps.get_model() call that\nretrieves models from the old app. This approach allows you to deploy your\nproject anywhere without first installing and then uninstalling the old app.
Here’s a sample migration:
\nmyapp/migrations/0124_move_old_app_to_new_app.pyfrom django.apps import apps as global_apps\nfrom django.db import migrations\n\ndef forwards(apps, schema_editor):\n try:\n OldModel = apps.get_model('old_app', 'OldModel')\n except LookupError:\n # The old app isn't installed.\n return\n\n NewModel = apps.get_model('new_app', 'NewModel')\n NewModel.objects.bulk_create(\n NewModel(new_attribute=old_object.old_attribute)\n for old_object in OldModel.objects.all()\n )\n\nclass Migration(migrations.Migration):\n operations = [\n migrations.RunPython(forwards, migrations.RunPython.noop),\n ]\n dependencies = [\n ('myapp', '0123_the_previous_migration'),\n ('new_app', '0001_initial'),\n ]\n\n if global_apps.is_installed('old_app'):\n dependencies.append(('old_app', '0001_initial'))\nAlso consider what you want to happen when the migration is unapplied. You\ncould either do nothing (as in the example above) or remove some or all of the\ndata from the new application. Adjust the second argument of the\nRunPython operation accordingly.