Migrações de dados

Este é o artigo final da nossa série de migrações do Django:

Parte 1:Migrações do Django - Uma introdução
Parte 2:aprofundando as migrações
Parte 3:Migrações de dados (artigo atual)
Vídeo:migrações do Django 1.7 - primer

De volta.

As migrações são principalmente para manter o modelo de dados do seu banco de dados atualizado, mas um banco de dados é mais do que apenas um modelo de dados. Mais notavelmente, também é uma grande coleção de dados. Portanto, qualquer discussão sobre migrações de banco de dados não estaria completa sem falar também sobre migrações de dados.

Atualizado em 12 de fevereiro de 2015 :alterou a migração de dados para pesquisar um modelo no registro do aplicativo.

Migrações de dados definidas

As migrações de dados são usadas em vários cenários. Dois muito populares são:

Quando você deseja carregar "dados do sistema" dos quais seu aplicativo depende de estar presente para operar com êxito.
Quando uma alteração em um modelo de dados força a necessidade de alterar os dados existentes.

Observe que o carregamento de dados fictícios para teste não está na lista acima. Você pode usar migrações para fazer isso, mas as migrações geralmente são executadas em servidores de produção, portanto, você provavelmente não deseja criar um monte de dados de teste fictícios em seu servidor de produção.

Exemplos

Continuando com o Projeto Django anterior, como exemplo de criação de alguns “dados do sistema”, vamos criar alguns preços históricos de bitcoin. As migrações do Django nos ajudarão, criando um arquivo de migração vazio e colocando-o no lugar certo se digitarmos:

$ ./manage.py makemigrations --empty historical_data

Isso deve criar um arquivo chamado historical_data/migrations/003_auto<date_time_stamp>.py . Vamos alterar o nome para 003_load_historical_data.py e depois abri-lo. Você terá uma estrutura padrão que se parece com:

# encoding: utf8
from django.db import models, migrations


class Migration(migrations.Migration):

    dependencies = [
        ('historical_data', '0002_auto_20140710_0810'),
    ]

    operations = [
    ]

Você pode ver que criou uma estrutura base para nós, e até inseriu as dependências. Isso é útil. Agora para fazer algumas migrações de dados, use o RunPython operação de migração:

# encoding: utf8
from django.db import models, migrations
from datetime import date

def load_data(apps, schema_editor):
    PriceHistory = apps.get_model("historical_data", "PriceHistory")

    PriceHistory(date=date(2013,11,29),
         price=1234.00,
         volume=354564,
         total_btc=12054375,
         ).save()
    PriceHistory(date=date(2012,11,29),
         price=12.15,
         volume=187947,
         total_btc=10504650,
         ).save()


class Migration(migrations.Migration):

    dependencies = [
        ('historical_data', '0002_auto_20140710_0810'),
    ]

    operations = [
        migrations.RunPython(load_data)
    ]

Começamos definindo a função load_data que - você adivinhou - carrega dados.

Para um aplicativo real, podemos acessar blockchain.info e obter a lista completa de preços históricos, mas apenas colocamos alguns para mostrar como a migração funciona.

Assim que tivermos a função, podemos chamá-la de nosso RunPython operação e então esta função será executada quando executarmos ./manage.py migrate da linha de comando.

Observe a linha:

PriceHistory = apps.get_model("historical_data", "PriceHistory")

Ao executar migrações, é importante obter a versão do nosso PriceHistory modelo que corresponde ao ponto da migração em que você está. Conforme você executa migrações, seu modelo (PriceHistory ) pode mudar se, por exemplo, você adicionar ou remover uma coluna em uma migração subsequente. Isso pode causar falha na migração de dados, a menos que você use a linha acima para obter a versão correta do modelo. Para saber mais sobre isso, veja o comentário aqui.

Isso é sem dúvida mais trabalhoso do que executar syncdb e fazer com que ele carregue um dispositivo elétrico. Na verdade, as migrações não respeitam os fixtures - o que significa que eles não os carregarão automaticamente para você como syncdb seria.

Isso se deve principalmente à filosofia.

Embora você possa usar migrações para carregar dados, elas tratam principalmente da migração de dados e/ou modelos de dados. Mostramos um exemplo de carregamento de dados do sistema, principalmente porque é uma explicação simples de como você configuraria uma migração de dados, mas muitas vezes as migrações de dados são usadas para ações mais complexas, como transformar seus dados para corresponder ao novo modelo de dados.

Um exemplo pode ser se decidíssemos começar a armazenar preços de várias bolsas em vez de apenas uma, para que pudéssemos adicionar campos como price_gox , price_btc , etc, poderíamos usar uma migração para mover todos os dados do price coluna para o price_btc coluna.

Em geral, ao lidar com migrações no Django 1.7, é melhor pensar em carregar dados como um exercício separado da migração do banco de dados. Se você quiser continuar a usar/carregar fixtures, você pode usar um comando como:

$ ./manage.py loaddata historical_data/fixtures/initial_data.json

Isso carregará os dados do equipamento no banco de dados.

Isso não acontece automaticamente como em uma migração de dados (o que provavelmente é uma coisa boa), mas a funcionalidade ainda está lá; ele não foi perdido, então sinta-se à vontade para continuar usando acessórios se precisar. A diferença é que agora você carrega dados com fixtures quando precisar. Isso é algo para se ter em mente se você estiver usando fixtures para carregar dados de teste para seus testes de unidade.

Conclusão

Isso, juntamente com os dois artigos anteriores, abrange os cenários mais comuns que você encontrará ao usar migrações. Existem muito mais cenários, e se você está curioso e realmente quer mergulhar nas migrações, o melhor lugar para ir (além do próprio código) são os documentos oficiais.

É o mais atualizado e faz um bom trabalho ao explicar como as coisas funcionam. Se houver um cenário mais complexo do qual você gostaria de ver um exemplo, informe-nos comentando abaixo.

Lembre-se de que, no caso geral, você está lidando com:

Migrações de esquema: Uma alteração na estrutura do banco de dados ou tabelas sem alteração nos dados. Este é o tipo mais comum, e o Django geralmente pode criar essas migrações para você automaticamente.
Migrações de dados: Uma alteração nos dados ou carregamento de novos dados. O Django não pode gerá-los para você. Eles devem ser criados manualmente usando o RunPython migração.

Portanto, escolha a migração correta para você, execute makemigrations e, em seguida, certifique-se de atualizar seus arquivos de migração toda vez que atualizar seu modelo - e é mais ou menos isso. Isso permitirá que você mantenha suas migrações armazenadas com seu código no git e garanta que você possa atualizar sua estrutura de banco de dados sem perder dados.

Boa migração!