Datamigreringar

Det här är den sista artikeln i vår Django-migreringsserie:

Del 1:Django Migrations - A Primer
Del 2:Gräva djupare i migrationer
Del 3:Datamigreringar (nuvarande artikel)
Video:Django 1.7 Migrations - primer

Tillbaka igen.

Migrationer är främst till för att hålla datamodellen för din databas uppdaterad, men en databas är mer än bara en datamodell. Framför allt är det också en stor samling data. Så varje diskussion om databasmigreringar skulle inte vara komplett utan att också prata om datamigreringar.

Uppdaterad 12 februari 2015 :Ändrade datamigreringen för att söka efter en modell från appregistret.

Datamigreringar definierade

Datamigreringar används i ett antal scenarier. Två mycket populära är:

När du vill ladda "systemdata" är din applikation beroende av att den är närvarande för att fungera framgångsrikt.
När en ändring av en datamodell tvingar fram behovet av att ändra befintliga data.

Observera att laddning av dummydata för testning inte finns i listan ovan. Du kan använda migrering för att göra det, men migreringar körs ofta på produktionsservrar, så du vill förmodligen inte skapa en massa dummy-testdata på din produktionsserver.

Exempel

För att fortsätta från det tidigare Django-projektet, som ett exempel på att skapa lite "systemdata", låt oss skapa några historiska bitcoin-priser. Django-migreringar hjälper oss genom att skapa en tom migreringsfil och placera den på rätt plats om vi skriver:

$ ./manage.py makemigrations --empty historical_data

Detta bör skapa en fil som heter historical_data/migrations/003_auto<date_time_stamp>.py . Låt oss ändra namnet till 003_load_historical_data.py och sedan öppna den. Du kommer att ha en standardstruktur som ser ut så här:

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


class Migration(migrations.Migration):

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

    operations = [
    ]

Du kan se att det har skapat en basstruktur för oss och till och med infogat beroenden. Det är till hjälp. För att göra några datamigreringar, använd RunPython migreringsoperation:

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

Vi börjar med att definiera funktionen load_data som - du gissade rätt - laddar data.

För en riktig app kanske vi vill gå ut till blockchain.info och ta den kompletta listan över historiska priser, men vi lägger bara in ett par där för att visa hur migreringen fungerar.

När vi väl har funktionen kan vi anropa den från vår RunPython operation och sedan kommer den här funktionen att köras när vi kör ./manage.py migrate från kommandoraden.

Notera raden:

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

När du kör migrering är det viktigt att skaffa versionen av vår PriceHistory modell som överensstämmer med den punkt i migrationen där du befinner dig. När du kör migreringar kommer din modell (PriceHistory ) kan ändras om du till exempel lägger till eller tar bort en kolumn i en efterföljande migrering. Detta kan göra att din datamigrering misslyckas, om du inte använder raden ovan för att få rätt version av modellen. För mer om detta, se kommentaren här.

Detta är utan tvekan mer arbete än att köra syncdb och låta den ladda en fixtur. Faktum är att migrering inte respekterar fixturer - vilket innebär att de inte automatiskt laddar dem åt dig som syncdb skulle.

Detta beror främst på filosofin.

Även om du kan använda migrering för att ladda data, handlar de främst om att migrera data och/eller datamodeller. Vi har visat ett exempel på att ladda systemdata, främst för att det är en enkel förklaring av hur du skulle ställa in en datamigrering, men ofta används datamigreringar för mer komplexa åtgärder som att transformera dina data för att matcha den nya datamodellen.

Ett exempel kan vara om vi bestämde oss för att börja lagra priser från flera börser istället för bara en, så att vi kan lägga till fält som price_gox , price_btc , etc, då kan vi använda en migrering för att flytta all data från price kolumnen till price_btc kolumn.

I allmänhet när man hanterar migrering i Django 1.7 är det bäst att tänka på att ladda data som en separat övning från att migrera databasen. Om du vill fortsätta att använda/ladda fixturer kan du använda ett kommando som:

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

Detta kommer att ladda data från fixturen till databasen.

Detta sker inte automatiskt som med en datamigrering (vilket förmodligen är bra), men funktionaliteten finns fortfarande kvar; den har inte gått förlorad, så fortsätt gärna att använda armaturer om du har ett behov. Skillnaden är att nu laddar du data med fixturer när du behöver det. Detta är något att tänka på om du använder fixturer för att ladda testdata för dina enhetstester.

Slutsats

Detta, tillsammans med de två föregående artiklarna, täcker de vanligaste scenarierna du kommer att stöta på när du använder migrering. Det finns många fler scenarier, och om du är nyfiken och verkligen vill dyka in i migrationer är det bästa stället att gå till (förutom själva koden) de officiella dokumenten.

Det är det mest uppdaterade och gör ett ganska bra jobb med att förklara hur saker fungerar. Om det finns ett mer komplext scenario som du skulle vilja se ett exempel på, vänligen meddela oss genom att kommentera nedan.

Kom ihåg att i det allmänna fallet har du att göra med antingen:

Schemamigreringar: En ändring av strukturen för databasen eller tabellerna utan ändring av data. Det här är den vanligaste typen, och Django kan i allmänhet skapa dessa migreringar åt dig automatiskt.
Datamigreringar: En ändring av data, eller laddning av ny data. Django kan inte generera dessa åt dig. De måste skapas manuellt med RunPython migration.

Så välj den migrering som är rätt för dig, kör makemigrations och se sedan bara till att uppdatera dina migreringsfiler varje gång du uppdaterar din modell – och det är mer eller mindre det. Det gör att du kan behålla dina migreringar lagrade med din kod i git och se till att du kan uppdatera din databasstruktur utan att behöva förlora data.

Lycka till med migreringen!