Datamigreringer

Dette er den sidste artikel i vores Django-migreringsserie:

Del 1:Django Migrations - A Primer
Del 2:Dybere ind i migrationer
Del 3:Datamigrering (aktuel artikel)
Video:Django 1.7 Migrations - primer

Tilbage igen.

Migreringer er primært for at holde datamodellen for din database opdateret, men en database er mere end blot en datamodel. Mest bemærkelsesværdigt er det også en stor samling af data. Så enhver diskussion om databasemigreringer ville ikke være komplet uden også at tale om datamigreringer.

Opdateret 12. februar 2015 :Ændrede datamigreringen for at slå en model op fra app-registret.

Datamigrationer defineret

Datamigrering bruges i en række scenarier. To meget populære er:

Når du gerne vil indlæse "systemdata", afhænger din applikation af at være til stede for at kunne fungere.
Når en ændring af en datamodel tvinger behovet for at ændre de eksisterende data.

Bemærk, at indlæsning af dummy-data til test ikke er på listen ovenfor. Du kan bruge migreringer til at gøre det, men migreringer køres ofte på produktionsservere, så du vil sandsynligvis ikke oprette en masse dummy-testdata på din produktionsserver.

Eksempler

For at fortsætte fra det forrige Django-projekt, som et eksempel på at skabe nogle "systemdata", lad os skabe nogle historiske bitcoin-priser. Django-migreringer vil hjælpe os ved at oprette en tom migreringsfil og placere den på det rigtige sted, hvis vi skriver:

$ ./manage.py makemigrations --empty historical_data

Dette skulle oprette en fil kaldet historical_data/migrations/003_auto<date_time_stamp>.py . Lad os ændre navnet til 003_load_historical_data.py og derefter åbne den. Du har en standardstruktur, der ser sådan ud:

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


class Migration(migrations.Migration):

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

    operations = [
    ]

Du kan se, at det har skabt en basisstruktur for os og endda indsat afhængighederne. Det er nyttigt. For nu at foretage nogle datamigreringer, brug 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 starter med at definere funktionen load_data som - du gættede rigtigt - indlæser data.

For en rigtig app vil vi måske gå ud til blockchain.info og få fat i den komplette liste over historiske priser, men vi har lige lagt et par ind der for at vise, hvordan migreringen fungerer.

Når vi har funktionen, kan vi kalde den fra vores RunPython operation, og så vil denne funktion blive udført, når vi kører ./manage.py migrate fra kommandolinjen.

Bemærk linjen:

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

Når du kører migreringer, er det vigtigt at få versionen af vores PriceHistory model, der svarer til det punkt i migrationen, hvor du befinder dig. Mens du kører migreringer, vil din model (PriceHistory ) kan ændres, hvis du f.eks. tilføjer eller fjerner en kolonne i en efterfølgende migrering. Dette kan få din datamigrering til at mislykkes, medmindre du bruger ovenstående linje til at få den korrekte version af modellen. For mere om dette, se venligst kommentaren her.

Dette er uden tvivl mere arbejde end at køre syncdb og få det til at indlæse et armatur. Faktisk respekterer migreringer ikke inventar - hvilket betyder, at de ikke automatisk indlæser dem for dig som syncdb ville.

Dette skyldes hovedsageligt filosofi.

Selvom du kunne bruge migreringer til at indlæse data, handler de hovedsageligt om migrering af data og/eller datamodeller. Vi har vist et eksempel på indlæsning af systemdata, primært fordi det er en simpel forklaring på, hvordan du ville konfigurere en datamigrering, men ofte bruges datamigreringer til mere komplekse handlinger som at transformere dine data, så de matcher den nye datamodel.

Et eksempel kan være, hvis vi besluttede at begynde at gemme priser fra flere børser i stedet for kun én, så vi kunne tilføje felter som price_gox , price_btc osv., så kunne vi bruge en migrering til at flytte alle data fra price kolonnen til price_btc kolonne.

Generelt, når man beskæftiger sig med migreringer i Django 1.7, er det bedst at tænke på indlæsning af data som en separat øvelse fra migrering af databasen. Hvis du vil fortsætte med at bruge/indlæse armaturer, kan du bruge en kommando som:

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

Dette vil indlæse data fra armaturet til databasen.

Dette sker ikke automatisk som ved en datamigrering (hvilket nok er en god ting), men funktionaliteten er der stadig; det er ikke gået tabt, så du er velkommen til at fortsætte med at bruge armaturer, hvis du har et behov. Forskellen er, at nu indlæser du data med inventar, når du har brug for det. Dette er noget, du skal huske på, hvis du bruger armaturer til at indlæse testdata til dine enhedstests.

Konklusion

Dette, sammen med de to foregående artikler, dækker de mest almindelige scenarier, du vil støde på, når du bruger migreringer. Der er mange flere scenarier, og hvis du er nysgerrig og virkelig ønsker at dykke ned i migrationer, er det bedste sted at tage hen (bortset fra selve koden) de officielle dokumenter.

Det er det mest opdaterede og gør et ret godt stykke arbejde med at forklare, hvordan tingene fungerer. Hvis der er et mere komplekst scenarie, som du gerne vil se et eksempel på, så lad os det vide ved at kommentere nedenfor.

Husk, at du i det generelle tilfælde har med enten:

at gøre

Skema-migreringer: En ændring af strukturen af databasen eller tabellerne uden ændring af dataene. Dette er den mest almindelige type, og Django kan generelt oprette disse migreringer for dig automatisk.
Datamigreringer: En ændring af dataene eller indlæsning af nye data. Django kan ikke generere disse for dig. De skal oprettes manuelt ved hjælp af RunPython migration.

Så vælg den migrering, der er korrekt for dig, kør makemigrations og så skal du bare sørge for at opdatere dine migreringsfiler, hver gang du opdaterer din model – og det er mere eller mindre det. Det vil give dig mulighed for at opbevare dine migreringer med din kode i git og sikre, at du kan opdatere din databasestruktur uden at skulle miste data.

God migrering!