Migraciones de datos

Este es el artículo final de nuestra serie de migraciones de Django:

Parte 1:Migraciones de Django - Introducción
Parte 2:profundizar en las migraciones
Parte 3:Migraciones de datos (artículo actual)
Video:Migraciones de Django 1.7:introducción

De vuelta otra vez.

Las migraciones son principalmente para mantener actualizado el modelo de datos de su base de datos, pero una base de datos es más que un modelo de datos. En particular, también es una gran colección de datos. Por lo tanto, cualquier discusión sobre migraciones de bases de datos no estaría completa sin hablar también sobre migraciones de datos.

Actualizado el 12 de febrero de 2015 :Cambió la migración de datos para buscar un modelo desde el registro de la aplicación.

Migraciones de datos definidas

Las migraciones de datos se utilizan en varios escenarios. Dos muy populares son:

Cuando desee cargar "datos del sistema" de los que depende su aplicación para funcionar correctamente.
Cuando un cambio en un modelo de datos fuerza la necesidad de cambiar los datos existentes.

Tenga en cuenta que la carga de datos ficticios para la prueba no se encuentra en la lista anterior. Podría usar migraciones para hacer eso, pero las migraciones a menudo se ejecutan en servidores de producción, por lo que probablemente no desee crear un montón de datos de prueba ficticios en su servidor de producción.

Ejemplos

Continuando con el Proyecto Django anterior, como ejemplo de creación de algunos "datos del sistema", creemos algunos precios históricos de bitcoin. Las migraciones de Django nos ayudarán creando un archivo de migración vacío y colocándolo en el lugar correcto si escribimos:

$ ./manage.py makemigrations --empty historical_data

Esto debería crear un archivo llamado historical_data/migrations/003_auto<date_time_stamp>.py . Cambiemos el nombre a 003_load_historical_data.py y luego abrirlo. Tendrá una estructura predeterminada que se parece a:

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


class Migration(migrations.Migration):

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

    operations = [
    ]

Puede ver que creó una estructura base para nosotros e incluso insertó las dependencias. Eso es útil. Ahora, para hacer algunas migraciones de datos, use RunPython operación de migración:

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

Comenzamos definiendo la función load_data que, lo adivinó, carga datos.

Para una aplicación real, es posible que deseemos ir a blockchain.info y obtener la lista completa de precios históricos, pero solo agregamos un par para mostrar cómo funciona la migración.

Una vez que tengamos la función podemos llamarla desde nuestro RunPython operación y luego esta función se ejecutará cuando ejecutemos ./manage.py migrate desde la línea de comando.

Toma nota de la línea:

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

Al ejecutar migraciones, es importante obtener la versión de nuestro PriceHistory modelo que corresponde con el punto de la migración en el que se encuentra. A medida que ejecuta migraciones, su modelo (PriceHistory ) puede cambiar si, por ejemplo, agrega o elimina una columna en una migración posterior. Esto puede hacer que falle la migración de datos, a menos que use la línea anterior para obtener la versión correcta del modelo. Para obtener más información sobre esto, consulte el comentario aquí.

Podría decirse que esto es más trabajo que ejecutar syncdb y hacer que cargue un accesorio. De hecho, las migraciones no respetan los accesorios, lo que significa que no los cargarán automáticamente como syncdb lo haría.

Esto se debe principalmente a la filosofía.

Si bien podría usar las migraciones para cargar datos, se trata principalmente de migrar datos y/o modelos de datos. Mostramos un ejemplo de carga de datos del sistema, principalmente porque es una explicación simple de cómo configuraría una migración de datos, pero a menudo, las migraciones de datos se usan para acciones más complejas como transformar sus datos para que coincidan con el nuevo modelo de datos.

Un ejemplo podría ser si decidiéramos comenzar a almacenar precios de varios intercambios en lugar de solo uno, por lo que podríamos agregar campos como price_gox , price_btc , etc., entonces podríamos usar una migración para mover todos los datos del price columna al price_btc columna.

En general, cuando se trata de migraciones en Django 1.7, es mejor pensar en la carga de datos como un ejercicio separado de la migración de la base de datos. Si desea continuar usando/cargando dispositivos, puede usar un comando como:

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

Esto cargará los datos del aparato en la base de datos.

Esto no sucede automáticamente como con una migración de datos (que probablemente sea algo bueno), pero la funcionalidad sigue ahí; no se ha perdido, así que siéntete libre de seguir usando accesorios si lo necesitas. La diferencia es que ahora carga datos con accesorios cuando los necesita. Esto es algo a tener en cuenta si está utilizando accesorios para cargar datos de prueba para sus pruebas unitarias.

Conclusión

Esto, junto con los dos artículos anteriores, cubre los escenarios más comunes que encontrará al usar migraciones. Hay muchos más escenarios, y si tiene curiosidad y realmente quiere sumergirse en las migraciones, el mejor lugar para ir (aparte del código en sí) es la documentación oficial.

Es el más actualizado y hace un buen trabajo al explicar cómo funcionan las cosas. Si hay un escenario más complejo del que le gustaría ver un ejemplo, háganoslo saber comentando a continuación.

Recuerde que, en el caso general, se trata de:

Migraciones de esquema: Un cambio en la estructura de la base de datos o tablas sin cambios en los datos. Este es el tipo más común y, por lo general, Django puede crear estas migraciones automáticamente.
Migraciones de datos: Un cambio en los datos o la carga de nuevos datos. Django no puede generarlos por ti. Deben crearse manualmente utilizando RunPython migración.

Así que elija la migración adecuada para usted, ejecute makemigrations y luego asegúrese de actualizar sus archivos de migración cada vez que actualice su modelo, y eso es más o menos todo. Eso le permitirá mantener sus migraciones almacenadas con su código en git y garantizar que pueda actualizar la estructura de su base de datos sin tener que perder datos.

¡Feliz migración!