Datenmigrationen

Dies ist der letzte Artikel unserer Django-Migrationsreihe:

Teil 1:Django-Migrationen – eine Einführung
Teil 2:Tiefer in Migrationen eintauchen
Teil 3:Datenmigrationen (aktueller Artikel)
Video:Django 1.7-Migrationen – Einführung

Wieder zurück.

Migrationen dienen hauptsächlich dazu, das Datenmodell Ihrer Datenbank auf dem neuesten Stand zu halten, aber eine Datenbank ist mehr als nur ein Datenmodell. Vor allem ist es auch eine große Sammlung von Daten. Daher wäre jede Diskussion über Datenbankmigrationen nicht vollständig, ohne auch über Datenmigrationen zu sprechen.

Aktualisiert am 12. Februar 2015 :Die Datenmigration wurde geändert, um ein Modell aus der App-Registrierung zu suchen.

Datenmigrationen definiert

Datenmigrationen werden in einer Reihe von Szenarien verwendet. Zwei sehr beliebte sind:

Wenn Sie „Systemdaten“ laden möchten, von denen Ihre Anwendung abhängig ist, um erfolgreich zu funktionieren.
Wenn eine Änderung an einem Datenmodell die Notwendigkeit erzwingt, die vorhandenen Daten zu ändern.

Beachten Sie, dass das Laden von Dummy-Daten zum Testen nicht in der obigen Liste enthalten ist. Dazu könnten Sie Migrationen verwenden, aber Migrationen werden häufig auf Produktionsservern ausgeführt, sodass Sie wahrscheinlich nicht einen Haufen Dummy-Testdaten auf Ihrem Produktionsserver erstellen möchten.

Beispiele

Lassen Sie uns in Fortsetzung des vorherigen Django-Projekts als Beispiel für die Erstellung einiger „Systemdaten“ einige historische Bitcoin-Preise erstellen. Django-Migrationen helfen uns dabei, indem sie eine leere Migrationsdatei erstellen und sie an der richtigen Stelle platzieren, wenn wir Folgendes eingeben:

$ ./manage.py makemigrations --empty historical_data

Dadurch sollte eine Datei namens historical_data/migrations/003_auto<date_time_stamp>.py erstellt werden . Ändern wir den Namen in 003_load_historical_data.py und öffne es dann. Sie haben eine Standardstruktur, die wie folgt aussieht:

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


class Migration(migrations.Migration):

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

    operations = [
    ]

Sie können sehen, dass es eine Basisstruktur für uns erstellt und sogar die Abhängigkeiten eingefügt hat. Das ist hilfreich. Um nun einige Datenmigrationen durchzuführen, verwenden Sie RunPython Migrationsvorgang:

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

Wir beginnen mit der Definition der Funktion load_data die - Sie haben es erraten - Daten lädt.

Für eine echte App möchten wir vielleicht zu blockchain.info gehen und die vollständige Liste der historischen Preise abrufen, aber wir haben dort nur ein paar eingefügt, um zu zeigen, wie die Migration funktioniert.

Sobald wir die Funktion haben, können wir sie von unserem RunPython aufrufen Operation und dann wird diese Funktion ausgeführt, wenn wir ./manage.py migrate ausführen über die Befehlszeile.

Beachten Sie die Zeile:

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

Beim Ausführen von Migrationen ist es wichtig, die Version unserer PriceHistory abzurufen Modell, das dem Zeitpunkt der Migration entspricht, an dem Sie sich befinden. Während Sie Migrationen ausführen, wird Ihr Modell (PriceHistory ) kann sich ändern, wenn Sie beispielsweise bei einer späteren Migration eine Spalte hinzufügen oder entfernen. Dies kann dazu führen, dass Ihre Datenmigration fehlschlägt, es sei denn, Sie verwenden die obige Zeile, um die richtige Version des Modells abzurufen. Weitere Informationen hierzu finden Sie im Kommentar hier.

Dies ist wohl mehr Arbeit als das Ausführen von syncdb und es ein Fixture laden zu lassen. Tatsächlich respektieren Migrationen Fixtures nicht – was bedeutet, dass sie sie nicht automatisch für Sie laden, wie syncdb würde.

Das liegt vor allem an der Philosophie.

Während Sie Migrationen zum Laden von Daten verwenden könnten, geht es dabei hauptsächlich um die Migration von Daten und/oder Datenmodellen. Wir haben ein Beispiel für das Laden von Systemdaten gezeigt, hauptsächlich weil es eine einfache Erklärung dafür ist, wie Sie eine Datenmigration einrichten würden, aber oft werden Datenmigrationen für komplexere Aktionen wie das Transformieren Ihrer Daten verwendet, um sie an das neue Datenmodell anzupassen.

Ein Beispiel wäre, wenn wir uns entschieden hätten, Preise von mehreren Börsen statt nur einer zu speichern, sodass wir Felder wie price_gox hinzufügen könnten , price_btc usw., dann könnten wir eine Migration verwenden, um alle Daten von price zu verschieben Spalte zum price_btc Spalte.

Im Allgemeinen ist es beim Umgang mit Migrationen in Django 1.7 am besten, das Laden von Daten als separate Übung von der Migration der Datenbank zu betrachten. Wenn Sie Fixtures weiterhin verwenden/laden möchten, können Sie einen Befehl wie diesen verwenden:

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

Dadurch werden Daten vom Gerät in die Datenbank geladen.

Dies geschieht nicht automatisch wie bei einer Datenmigration (was wahrscheinlich eine gute Sache ist), aber die Funktionalität ist immer noch vorhanden; Es ist nicht verloren gegangen, also können Sie die Vorrichtungen weiterhin verwenden, wenn Sie Bedarf haben. Der Unterschied besteht darin, dass Sie jetzt Daten mit Fixtures laden, wenn Sie sie brauchen. Dies sollten Sie bedenken, wenn Sie Fixtures verwenden, um Testdaten für Ihre Komponententests zu laden.

Schlussfolgerung

Dies deckt zusammen mit den beiden vorherigen Artikeln die häufigsten Szenarien ab, denen Sie bei der Verwendung von Migrationen begegnen werden. Es gibt noch viel mehr Szenarien, und wenn Sie neugierig sind und wirklich in Migrationen eintauchen möchten, ist die beste Anlaufstelle (abgesehen vom Code selbst) die offizielle Dokumentation.

Es ist das aktuellste und erklärt ziemlich gut, wie die Dinge funktionieren. Wenn es ein komplexeres Szenario gibt, für das Sie gerne ein Beispiel sehen möchten, teilen Sie uns dies bitte mit, indem Sie unten einen Kommentar abgeben.

Denken Sie daran, dass Sie es im Allgemeinen mit einem von beiden zu tun haben:

Schemamigrationen: Eine Änderung der Struktur der Datenbank oder der Tabellen ohne Änderung der Daten. Dies ist der häufigste Typ, und Django kann diese Migrationen im Allgemeinen automatisch für Sie erstellen.
Datenmigrationen: Eine Änderung der Daten oder das Laden neuer Daten. Django kann diese nicht für Sie generieren. Sie müssen manuell mit RunPython erstellt werden Migration.

Wählen Sie also die für Sie richtige Migration aus und führen Sie makemigrations aus und stellen Sie dann einfach sicher, dass Sie Ihre Migrationsdateien jedes Mal aktualisieren, wenn Sie Ihr Modell aktualisieren – und das war es mehr oder weniger. Dadurch können Sie Ihre Migrationen mit Ihrem Code in Git speichern und sicherstellen, dass Sie Ihre Datenbankstruktur aktualisieren können, ohne Daten verlieren zu müssen.

Viel Spaß beim Umziehen!