Gegevensmigraties

Dit is het laatste artikel in onze serie Django-migraties:

Deel 1:Django-migraties - Een primeur
Deel 2:Dieper graven in migraties
Deel 3:Gegevensmigraties (huidig artikel)
Video:Django 1.7-migraties - primer

Weer terug.

Migraties zijn er vooral om het datamodel van uw database up-to-date te houden, maar een database is meer dan alleen een datamodel. Het meest opvallende is dat het ook een grote verzameling gegevens is. Dus elke discussie over databasemigraties zou niet compleet zijn zonder ook over gegevensmigraties te praten.

Bijgewerkt op 12 februari 2015 :de gegevensmigratie gewijzigd om een model op te zoeken in het app-register.

Gedefinieerde gegevensmigraties

Datamigraties worden in een aantal scenario's gebruikt. Twee zeer populaire zijn:

Als u "systeemgegevens" wilt laden waarvan uw toepassing afhankelijk is om succesvol te kunnen werken.
Wanneer een wijziging in een gegevensmodel de noodzaak dwingt om de bestaande gegevens te wijzigen.

Houd er rekening mee dat het laden van dummy-gegevens voor testen niet in de bovenstaande lijst staat. Je zou migraties kunnen gebruiken om dat te doen, maar migraties worden vaak uitgevoerd op productieservers, dus je wilt waarschijnlijk niet een hoop dummy-testgegevens maken op je productieserver.

Voorbeelden

Voortbordurend op het vorige Django-project, laten we als voorbeeld van het maken van enkele "systeemgegevens" enkele historische bitcoin-prijzen maken. Django-migraties helpen ons door een leeg migratiebestand te maken en op de juiste plaats te zetten als we typen:

$ ./manage.py makemigrations --empty historical_data

Dit zou een bestand moeten maken met de naam historical_data/migrations/003_auto<date_time_stamp>.py . Laten we de naam veranderen in 003_load_historical_data.py en open het dan. Je hebt een standaardstructuur die er als volgt uitziet:

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


class Migration(migrations.Migration):

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

    operations = [
    ]

Je kunt zien dat het een basisstructuur voor ons heeft gemaakt en zelfs de afhankelijkheden heeft ingevoegd. Dat is handig. Om nu wat gegevensmigraties uit te voeren, gebruikt u de RunPython migratiebewerking:

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

We beginnen met het definiëren van de functie load_data die - je raadt het al - gegevens laadt.

Voor een echte app willen we misschien naar blockchain.info gaan en de volledige lijst met historische prijzen pakken, maar we hebben er gewoon een paar toegevoegd om te laten zien hoe de migratie werkt.

Zodra we de functie hebben, kunnen we deze aanroepen vanuit onze RunPython bewerking en dan wordt deze functie uitgevoerd wanneer we ./manage.py migrate . uitvoeren vanaf de opdrachtregel.

Let op de regel:

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

Bij het uitvoeren van migraties is het belangrijk om de versie van onze PriceHistory model dat overeenkomt met het punt in de migratie waar u zich bevindt. Terwijl u migraties uitvoert, wordt uw model (PriceHistory ) kunnen wijzigen, bijvoorbeeld als u bij een volgende migratie een kolom toevoegt of verwijdert. Dit kan ertoe leiden dat uw gegevensmigratie mislukt, tenzij u de bovenstaande regel gebruikt om de juiste versie van het model te krijgen. Zie de opmerking hier voor meer informatie.

Dit is aantoonbaar meer werk dan het uitvoeren van syncdb en een armatuur laten laden. In feite respecteren migraties de armaturen niet - wat betekent dat ze ze niet automatisch voor je laden zoals syncdb zou.

Dit komt voornamelijk door de filosofie.

Hoewel je migraties zou kunnen gebruiken om data te laden, gaat het vooral om het migreren van data en/of datamodellen. We hebben een voorbeeld getoond van het laden van systeemgegevens, voornamelijk omdat het een eenvoudige uitleg is van hoe u een gegevensmigratie zou opzetten, maar vaak worden gegevensmigraties gebruikt voor complexere acties, zoals het transformeren van uw gegevens zodat ze passen bij het nieuwe gegevensmodel.

Een voorbeeld kan zijn als we besluiten om prijzen van meerdere beurzen op te slaan in plaats van slechts één, zodat we velden kunnen toevoegen zoals price_gox , price_btc , etc, dan kunnen we een migratie gebruiken om alle gegevens van de price . te verplaatsen kolom naar de price_btc kolom.

Over het algemeen is het bij het omgaan met migraties in Django 1.7 het beste om het laden van gegevens te zien als een aparte oefening van het migreren van de database. Als je de fixtures wilt blijven gebruiken/laden, kun je een commando gebruiken als:

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

Dit zal de data van de fixture in de database laden.

Dit gebeurt niet automatisch zoals bij een datamigratie (wat waarschijnlijk een goede zaak is), maar de functionaliteit is er nog steeds; het is niet verloren gegaan, dus voel je vrij om armaturen te blijven gebruiken als je dat nodig hebt. Het verschil is dat je nu data met fixtures laadt wanneer je het nodig hebt. Dit is iets om in gedachten te houden als u fixtures gebruikt om testgegevens voor uw unit-tests te laden.

Conclusie

Dit behandelt, samen met de vorige twee artikelen, de meest voorkomende scenario's die u tegenkomt bij het gebruik van migraties. Er zijn nog veel meer scenario's, en als je nieuwsgierig bent en echt in migraties wilt duiken, kun je het beste gaan (behalve de code zelf) de officiële documenten.

Het is het meest up-to-date en legt redelijk goed uit hoe dingen werken. Als er een complexer scenario is waarvan u een voorbeeld zou willen zien, laat het ons dan weten door hieronder te reageren.

Onthoud dat u in het algemeen te maken heeft met:

Schemamigraties: Een wijziging in de structuur van de database of tabellen zonder wijziging van de gegevens. Dit is het meest voorkomende type en Django kan deze migraties over het algemeen automatisch voor u maken.
Gegevensmigraties: Een wijziging in de gegevens, of het laden van nieuwe gegevens. Django kan deze niet voor u genereren. Ze moeten handmatig worden gemaakt met behulp van de RunPython migratie.

Dus kies de migratie die voor jou de juiste is, voer makemigrations uit en zorg er vervolgens voor dat u uw migratiebestanden bijwerkt telkens wanneer u uw model bijwerkt - en dat is het min of meer. Zo kunt u uw migraties met uw code in git bewaren en ervoor zorgen dat u uw databasestructuur kunt bijwerken zonder gegevens te verliezen.

Veel succes met migreren!