---
title: "Escrevendo migrações de banco de dados"
version: 1.9
locale: pt-br
source: https://docs.djangoproject.com/pt-br/1.9/howto/writing-migrations/
canonical: https://djangodocs.dev/pt-br/1.9/howto/writing-migrations/
---
# Escrevendo migrações de banco de dados

Este documento explica como estruturar e a escrever migrações de banco de dados para diferentes cenários que você talvez encontre.

## Migrações de dados e múltimplos bancos de dados

Quando 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.

Para 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

def forwards(apps, schema_editor):
    if not schema_editor.connection.alias == 'default':
        return
    # Your migration code goes here

class Migration(migrations.Migration):

    dependencies = [
        # Dependencies to other migrations
    ]

    operations = [
        migrations.RunPython(forwards),
    ]
```

> **New in Django 1.8**

Você pode fornecer dicas que serão passadas para o método [`allow_migrate()`](/pt-br/1.9/topics/db/multi-db/#allow_migrate) do roteador de banco de dados como `**hints`:

*myapp/dbrouters.py*

```
class MyRouter(object):

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        if 'target_db' in hints:
            return db == hints['target_db']
        return True
```

Então para aproveitar isso em suas migrações, faça o seguinte:

```
from django.db import migrations

def forwards(apps, schema_editor):
    # Your migration code goes here
    ...

class Migration(migrations.Migration):

    dependencies = [
        # Dependencies to other migrations
    ]

    operations = [
        migrations.RunPython(forwards, hints={'target_db': 'default'}),
    ]
```

Se 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.

## Migrações que adicionam campos “unique”

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”.

Portanto, os seguintes passos devem ser seguidos. Neste exemplo, nós iremos adicionar um [`UUIDField`](/pt-br/1.9/ref/models/fields/#django.db.models.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`](/pt-br/1.9/ref/django-admin/#django-admin-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 -*-
  # Generated by Django A.B on YYYY-MM-DD HH:MM
  from __future__ import unicode_literals

  from django.db import migrations, models
  import uuid

  class Migration(migrations.Migration):

      dependencies = [
          ('myapp', '0005_populate_uuid_values'),
      ]

      operations = [
          migrations.AlterField(
              model_name='mymodel',
              name='uuid',
              field=models.UUIDField(default=uuid.uuid4, unique=True),
          ),
      ]
  ```
- Edite o primeiro arquivo da migração. A classe de migração gerada deve se parecer com isso:

  *0004_add_uuid_field.py*

  ```
  class Migration(migrations.Migration):

      dependencies = [
          ('myapp', '0003_auto_20150129_1705'),
      ]

      operations = [
          migrations.AddField(
              model_name='mymodel',
              name='uuid',
              field=models.UUIDField(default=uuid.uuid4, unique=True),
          ),
      ]
  ```

  Mude `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`](/pt-br/1.9/ref/migration-operations/#django.db.migrations.operations.RunPython) ou uma operaçãoi [`RunSQL`](/pt-br/1.9/ref/migration-operations/#django.db.migrations.operations.RunSQL) para gerar os valores únicos(UUID no exemplo) para cada registro existente. Por exemplo:

  *0005_populate_uuid_values.py*

  ```
  # -*- coding: utf-8 -*-
  # Generated by Django A.B on YYYY-MM-DD HH:MM
  from __future__ import unicode_literals

  from django.db import migrations, models
  import uuid

  def gen_uuid(apps, schema_editor):
      MyModel = apps.get_model('myapp', 'MyModel')
      for row in MyModel.objects.all():
          row.uuid = uuid.uuid4()
          row.save()

  class Migration(migrations.Migration):

      dependencies = [
          ('myapp', '0004_add_uuid_field'),
      ]

      operations = [
          # omit reverse_code=... if you don't want the migration to be reversible.
          migrations.RunPython(gen_uuid, reverse_code=migrations.RunPython.noop),
      ]
  ```
- Agora você pode aplicar as migrações como de costume com o comando [`migrate`](/pt-br/1.9/ref/django-admin/#django-admin-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.

## Controlando a ordem das migrações

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

class Migration(migrations.Migration):

    dependencies = [
        ('myapp', '0123_the_previous_migration'),
    ]
```

Normalmente 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`](/pt-br/1.9/ref/settings/#std-setting-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):
    ...

    run_before = [
        ('third_party_app', '0001_do_awesome'),
    ]
```

Prefira 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.

## Migrating data between third-party apps

You can use a data migration to move data from one third-party application to
another.

If you plan to remove the old app later, you’ll need to set the `dependencies`
property based on whether or not the old app is installed. Otherwise, you’ll
have missing dependencies once you uninstall the old app. Similarly, you’ll
need to catch [`LookupError`](https://docs.python.org/3/library/exceptions.html#LookupError) in the `apps.get_model()` call that
retrieves models from the old app. This approach allows you to deploy your
project anywhere without first installing and then uninstalling the old app.

Here’s a sample migration:

*myapp/migrations/0124_move_old_app_to_new_app.py*

```
from django.apps import apps as global_apps
from django.db import migrations

def forwards(apps, schema_editor):
    try:
        OldModel = apps.get_model('old_app', 'OldModel')
    except LookupError:
        # The old app isn't installed.
        return

    NewModel = apps.get_model('new_app', 'NewModel')
    NewModel.objects.bulk_create(
        NewModel(new_attribute=old_object.old_attribute)
        for old_object in OldModel.objects.all()
    )

class Migration(migrations.Migration):
    operations = [
        migrations.RunPython(forwards, migrations.RunPython.noop),
    ]
    dependencies = [
        ('myapp', '0123_the_previous_migration'),
        ('new_app', '0001_initial'),
    ]

    if global_apps.is_installed('old_app'):
        dependencies.append(('old_app', '0001_initial'))
```

Also consider what you want to happen when the migration is unapplied. You
could either do nothing (as in the example above) or remove some or all of the
data from the new application. Adjust the second argument of the
[`RunPython`](/pt-br/1.9/ref/migration-operations/#django.db.migrations.operations.RunPython) operation accordingly.