Migracje danych

To jest ostatni artykuł z naszej serii migracji Django:

Część 1:Migracje Django — elementarz
Część 2:Zagłębianie się w migracje
Część 3:Migracje danych (aktualny artykuł)
Wideo:Migracje Django 1.7 – wprowadzenie

Z powrotem.

Migracje służą głównie do utrzymywania aktualności modelu danych bazy danych, ale baza danych to coś więcej niż tylko model danych. Przede wszystkim jest to również duży zbiór danych. Więc jakakolwiek dyskusja na temat migracji baz danych nie byłaby kompletna bez omówienia migracji danych.

Zaktualizowano 12 lutego 2015 r. :Zmieniono migrację danych, aby wyszukać model z rejestru aplikacji.

Zdefiniowane migracje danych

Migracje danych są używane w wielu scenariuszach. Dwa bardzo popularne to:

Kiedy chcesz załadować „dane systemowe”, od których Twoja aplikacja zależy, aby działała pomyślnie.
Gdy zmiana w modelu danych wymusza konieczność zmiany istniejących danych.

Zwróć uwagę, że ładowanie fikcyjnych danych do testowania nie znajduje się na powyższej liście. Możesz użyć migracji, aby to zrobić, ale migracje są często uruchamiane na serwerach produkcyjnych, więc prawdopodobnie nie chcesz tworzyć wielu fikcyjnych danych testowych na serwerze produkcyjnym.

Przykłady

Kontynuując poprzedni projekt Django, jako przykład tworzenia „danych systemowych”, stwórzmy historyczne ceny bitcoinów. Migracje Django pomogą nam, tworząc pusty plik migracji i umieszczając go we właściwym miejscu, jeśli wpiszemy:

$ ./manage.py makemigrations --empty historical_data

Powinno to spowodować utworzenie pliku o nazwie historical_data/migrations/003_auto<date_time_stamp>.py . Zmieńmy nazwę na 003_load_historical_data.py a następnie otwórz go. Będziesz mieć domyślną strukturę, która wygląda następująco:

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


class Migration(migrations.Migration):

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

    operations = [
    ]

Widać, że stworzył dla nas podstawową strukturę, a nawet wstawił zależności. To pomocne. Teraz, aby wykonać migracje danych, użyj RunPython operacja migracji:

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

Zaczynamy od zdefiniowania funkcji load_data który – zgadłeś – ładuje dane.

W przypadku prawdziwej aplikacji możemy chcieć wejść na blockchain.info i pobrać pełną listę historycznych cen, ale po prostu umieściliśmy tam kilka, aby pokazać, jak działa migracja.

Gdy już mamy funkcję, możemy ją wywołać z naszego RunPython operacji, a następnie ta funkcja zostanie wykonana, gdy uruchomimy ./manage.py migrate z wiersza poleceń.

Zwróć uwagę na linię:

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

Podczas przeprowadzania migracji ważne jest, aby pobrać wersję naszej PriceHistory model, który odpowiada punktowi migracji, w którym się znajdujesz. Podczas uruchamiania migracji Twój model (PriceHistory ) może ulec zmianie, jeśli na przykład dodasz lub usuniesz kolumnę w kolejnej migracji. Może to spowodować niepowodzenie migracji danych, chyba że użyjesz powyższego wiersza, aby uzyskać poprawną wersję modelu. Więcej informacji na ten temat można znaleźć w komentarzu tutaj.

Jest to prawdopodobnie więcej pracy niż uruchomienie syncdb i ładowanie urządzenia. W rzeczywistości migracje nie uwzględniają urządzeń - co oznacza, że nie będą one automatycznie ładować ich za Ciebie, jak syncdb zrobiłby.

Wynika to głównie z filozofii.

Chociaż można użyć migracji do ładowania danych, dotyczą one głównie migracji danych i/lub modeli danych. Pokazaliśmy przykład ładowania danych systemowych, głównie dlatego, że jest to proste wyjaśnienie, jak skonfigurować migrację danych, ale często migracje danych są używane do bardziej złożonych działań, takich jak przekształcanie danych w celu dopasowania do nowego modelu danych.

Przykładem może być sytuacja, w której zdecydowaliśmy się zacząć przechowywać ceny z wielu giełd zamiast z jednej, dzięki czemu moglibyśmy dodać pola takie jak price_gox , price_btc itp., wtedy moglibyśmy użyć migracji, aby przenieść wszystkie dane z price kolumna do price_btc kolumna.

Ogólnie rzecz biorąc, mając do czynienia z migracjami w Django 1.7, najlepiej myśleć o ładowaniu danych jako oddzielnym ćwiczeniu od migracji bazy danych. Jeśli chcesz nadal używać/ładować urządzenia, możesz użyć polecenia takiego jak:

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

Spowoduje to załadowanie danych z urządzenia do bazy danych.

Nie dzieje się to automatycznie, jak w przypadku migracji danych (co prawdopodobnie jest dobrą rzeczą), ale funkcjonalność nadal istnieje; nie zgubił się, więc możesz nadal używać osprzętu, jeśli masz taką potrzebę. Różnica polega na tym, że teraz ładujesz dane z urządzeniami, kiedy tego potrzebujesz. Należy o tym pamiętać, jeśli używasz urządzeń do ładowania danych testowych do testów jednostkowych.

Wniosek

To, wraz z poprzednimi dwoma artykułami, obejmuje najczęstsze scenariusze, z którymi możesz się spotkać podczas korzystania z migracji. Istnieje wiele innych scenariuszy, a jeśli jesteś ciekawy i naprawdę chcesz zagłębić się w migracje, najlepszym miejscem (poza samym kodem) są oficjalne dokumenty.

Jest najbardziej aktualny i całkiem nieźle wyjaśnia, jak to działa. Jeśli istnieje bardziej złożony scenariusz, którego przykład chciałbyś zobaczyć, poinformuj nas o tym, komentując poniżej.

Pamiętaj, że w ogólnym przypadku masz do czynienia z:

Migracje schematów: Zmiana struktury bazy danych lub tabel bez zmiany danych. Jest to najpopularniejszy typ, a Django może zazwyczaj automatycznie tworzyć te migracje.
Migracje danych: Zmiana danych lub wczytanie nowych danych. Django nie może ich dla ciebie wygenerować. Muszą być tworzone ręcznie za pomocą RunPython migracja.

Wybierz więc migrację, która jest dla Ciebie odpowiednia, uruchom makemigrations a potem po prostu pamiętaj, aby aktualizować pliki migracji za każdym razem, gdy aktualizujesz swój model — i to mniej więcej. Umożliwi to przechowywanie migracji z kodem w git i zapewni, że będziesz mógł aktualizować strukturę bazy danych bez utraty danych.

Miłej migracji!