Миграции на данни

Това е последната статия в нашата серия за миграции на Django:

Част 1:Django Migrations – A Primer
Част 2:Копаене по-дълбоко в миграциите
Част 3:Миграции на данни (текуща статия)
Видео:Миграции на Django 1.7 – начален курс

Отново.

Миграциите са основно за поддържане на актуален модел на данни на вашата база данни, но базата данни е нещо повече от модел на данни. Най-вече, това е и голяма колекция от данни. Така че всяко обсъждане на миграциите на бази данни не би било пълно, без да говорим и за миграциите на данни.

Актуализирано на 12 февруари 2015 г. :Променено миграцията на данни за търсене на модел от регистъра на приложенията.

Дефинирани миграции на данни

Миграцията на данни се използва в редица сценарии. Две много популярни са:

Когато искате да заредите „системни данни“, за успешното функциониране на приложението ви зависи от присъствието му.
Когато промяна в модел на данни налага необходимостта от промяна на съществуващите данни.

Имайте предвид, че зареждането на фиктивни данни за тестване не е в горния списък. Можете да използвате миграции, за да направите това, но миграциите често се изпълняват на производствени сървъри, така че вероятно не искате да създавате куп фиктивни тестови данни на вашия производствен сървър.

Примери

Продължавайки от предишния проект Django, като пример за създаване на някои „системни данни“, нека създадем някои исторически цени на биткойн. Django миграциите ще ни помогнат, като създадем празен файл за миграция и го поставим на правилното място, ако напишем:

$ ./manage.py makemigrations --empty historical_data

Това трябва да създаде файл, наречен historical_data/migrations/003_auto<date_time_stamp>.py . Нека променим името на 003_load_historical_data.py и след това го отворете. Ще имате структура по подразбиране, която изглежда така:

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


class Migration(migrations.Migration):

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

    operations = [
    ]

Можете да видите, че е създал базова структура за нас и дори е вмъкнал зависимостите. Това е полезно. Сега, за да извършите някои миграции на данни, използвайте RunPython операция по миграция:

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

Започваме с дефиниране на функцията load_data което - познахте - зарежда данни.

За истинско приложение може да искаме да отидем на blockchain.info и да вземем пълния списък с исторически цени, но просто поставихме няколко там, за да покажем как работи миграцията.

След като имаме функцията, можем да я извикаме от нашия RunPython операция и след това тази функция ще се изпълни, когато изпълним ./manage.py migrate от командния ред.

Обърнете внимание на реда:

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

Когато изпълнявате миграции, е важно да получите версията на нашата PriceHistory модел, който съответства на точката от миграцията, в която се намирате. Докато изпълнявате миграции, вашият модел (PriceHistory ) може да се промени, ако например добавите или премахнете колона при следваща миграция. Това може да доведе до неуспешна миграция на данни, освен ако не използвате горния ред, за да получите правилната версия на модела. За повече информация, моля, вижте коментара тук.

Това е може би повече работа от стартирането на syncdb и като го зареди приспособление. Всъщност миграциите не зачитат фиксираните елементи - което означава, че няма да ги заредят автоматично вместо вас като syncdb би.

Това се дължи главно на философията.

Въпреки че бихте могли да използвате миграции за зареждане на данни, те са основно за мигриране на данни и/или модели на данни. Показахме пример за зареждане на системни данни, главно защото това е просто обяснение за това как бихте настроили миграция на данни, но често пъти миграциите на данни се използват за по-сложни действия като трансформиране на вашите данни, за да съответстват на новия модел на данни.

Пример може да бъде, ако решим да започнем да съхраняваме цени от множество борси вместо само от една, така че можем да добавим полета като price_gox , price_btc и т.н., тогава бихме могли да използваме миграция, за да преместим всички данни от price колона към price_btc колона.

Като цяло, когато се занимавате с миграции в Django 1.7, най-добре е да мислите за зареждането на данни като отделно упражнение от мигрирането на базата данни. Ако искате да продължите да използвате/зареждате приспособления, можете да използвате команда като:

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

Това ще зареди данни от устройството в базата данни.

Това не се случва автоматично, както при миграция на данни (което вероятно е добро), но функционалността все още е налице; не е изгубен, така че не се колебайте да продължите да използвате приспособления, ако имате нужда. Разликата е, че сега зареждате данни с тела, когато имате нужда от тях. Това е нещо, което трябва да имате предвид, ако използвате приспособления за зареждане на тестови данни за вашите модулни тестове.

Заключение

Това, заедно с предишните две статии, обхваща най-често срещаните сценарии, които ще срещнете, когато използвате миграции. Има още много сценарии и ако сте любопитни и наистина искате да се потопите в миграциите, най-доброто място за посещение (освен самия код) са официалните документи.

Той е най-актуалният и върши доста добра работа, за да обясни как работят нещата. Ако има по-сложен сценарий, за който бихте искали да видите пример, моля, уведомете ни, като коментирате по-долу.

Не забравяйте, че в общия случай имате работа с едно от следните:

Миграции на схеми: Промяна в структурата на базата данни или таблиците без промяна в данните. Това е най-често срещаният тип и Django обикновено може да създаде тези миграции автоматично за вас.
Миграции на данни: Промяна на данните или зареждане на нови данни. Django не може да генерира тези за вас. Те трябва да бъдат създадени ръчно с помощта на RunPython миграция.

Така че изберете миграцията, която е правилна за вас, стартирайте makemigrations и след това просто не забравяйте да актуализирате вашите миграционни файлове всеки път, когато актуализирате модела си - и това е горе-долу всичко. Това ще ви позволи да запазите вашите миграции, съхранени с вашия код в git, и ще гарантирате, че можете да актуализирате структурата на вашата база данни, без да се налага да губите данни.

Приятна миграция!