Toto je poslední článek z naší série migrací Django:
- Část 1:Django Migrations – A Primer
- Část 2:Ponoření se hlouběji do migrace
- Část 3:Migrace dat (aktuální článek)
- Video:Migrace Django 1.7 – základní verze
Znovu zpět.
Migrace slouží hlavně k udržení aktuálního datového modelu vaší databáze, ale databáze je více než jen datový model. Především je to také velká sbírka dat. Jakákoli diskuse o migracích databází by tedy nebyla úplná, aniž by se také nemluvilo o migracích dat.
Aktualizováno 12. února 2015 :Změna migrace dat na vyhledání modelu z registru aplikací.
Definice migrace dat
Migrace dat se používají v řadě scénářů. Dva velmi oblíbené jsou:
- Pokud chcete načíst „systémová data“, závisí na tom, zda je vaše aplikace přítomna, aby úspěšně fungovala.
- Když si změna datového modelu vynutí potřebu změnit stávající data.
Upozorňujeme, že načítání fiktivních dat pro testování není ve výše uvedeném seznamu. K tomu byste mohli použít migrace, ale migrace se často spouštějí na produkčních serverech, takže pravděpodobně nebudete chtít na svém produkčním serveru vytvářet hromadu fiktivních testovacích dat.
Příklady
V návaznosti na předchozí projekt Django, jako příklad vytvoření některých „systémových dat“, vytvořte některé historické ceny bitcoinů. Migrace Django nám pomohou vytvořením prázdného migračního souboru a jeho umístěním na správné místo, pokud napíšeme:
$ ./manage.py makemigrations --empty historical_data
Tím by se měl vytvořit soubor s názvem historical_data/migrations/003_auto<date_time_stamp>.py
. Změňme název na 003_load_historical_data.py
a pak to otevřete. Budete mít výchozí strukturu, která vypadá takto:
# encoding: utf8
from django.db import models, migrations
class Migration(migrations.Migration):
dependencies = [
('historical_data', '0002_auto_20140710_0810'),
]
operations = [
]
Můžete vidět, že to pro nás vytvořilo základní strukturu a dokonce vložilo závislosti. To je užitečné. Chcete-li nyní provést migraci dat, použijte RunPython
operace migrace:
# 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)
]
Začneme definováním funkce load_data
který – uhodli jste – načítá data.
Pro skutečnou aplikaci bychom možná chtěli jít na blockchain.info a získat kompletní seznam historických cen, ale vložili jsme tam jen pár, abychom ukázali, jak migrace funguje.
Jakmile máme funkci, můžeme ji volat z našeho RunPython
operaci a poté se tato funkce provede, když spustíme ./manage.py migrate
z příkazového řádku.
Poznamenejte si řádek:
PriceHistory = apps.get_model("historical_data", "PriceHistory")
Při spouštění migrací je důležité získat verzi naší PriceHistory
model, který odpovídá bodu migrace, kde se nacházíte. Při spouštění migrací se váš model (PriceHistory
) se může změnit, pokud například přidáte nebo odeberete sloupec při následné migraci. To může způsobit selhání migrace dat, pokud nepoužijete výše uvedený řádek k získání správné verze modelu. Více o tom najdete v komentáři zde.
To je pravděpodobně více práce než spuštění syncdb
a nechat to načíst přípravek. Ve skutečnosti migrace nerespektují příslušenství – to znamená, že je automaticky nenačtou za vás jako syncdb
by.
Je to dáno především filozofií.
I když můžete migrace použít k načtení dat, jedná se hlavně o migraci dat a/nebo datových modelů. Ukázali jsme příklad načítání systémových dat, hlavně proto, že jde o jednoduché vysvětlení, jak byste nastavili migraci dat, ale často se migrace dat používají pro složitější akce, jako je transformace dat tak, aby odpovídala novému datovému modelu.
Příkladem může být, kdybychom se rozhodli začít ukládat ceny z více burz namísto pouze jedné, takže bychom mohli přidat pole jako price_gox
, price_btc
, atd., pak bychom mohli pomocí migrace přesunout všechna data z price
do sloupce price_btc
sloupec.
Obecně je při řešení migrací v Django 1.7 nejlepší uvažovat o načítání dat jako o samostatném cvičení od migrace databáze. Pokud chcete pokračovat v používání/načítání zařízení, můžete použít příkaz jako:
$ ./manage.py loaddata historical_data/fixtures/initial_data.json
Tím se načtou data ze zařízení do databáze.
To se nestane automaticky jako u migrace dat (což je pravděpodobně dobrá věc), ale funkce je stále k dispozici; neztratilo se, takže v případě potřeby můžete pokračovat v používání příslušenství. Rozdíl je v tom, že nyní načítáte data zařízeními, když je potřebujete. To je něco, co je třeba mít na paměti, pokud používáte zařízení k načítání testovacích dat pro vaše testy jednotek.
Závěr
Toto spolu s předchozími dvěma články pokrývá nejběžnější scénáře, se kterými se při používání migrací setkáte. Existuje spousta dalších scénářů, a pokud jste zvědaví a opravdu se chcete ponořit do migrace, nejlepším místem, kam jít (kromě samotného kódu), jsou oficiální dokumenty.
Je to nejaktuálnější a docela dobře vysvětluje, jak věci fungují. Pokud existuje složitější scénář, jehož příklad byste chtěli vidět, dejte nám prosím vědět komentářem níže.
Pamatujte, že v obecném případě máte co do činění s:
-
Migrace schémat: Změna struktury databáze nebo tabulek beze změny dat. Toto je nejběžnější typ a Django obecně může tyto migrace vytvořit za vás automaticky.
-
Migrace dat: Změna dat nebo načtení nových dat. Django je nemůže vygenerovat za vás. Musí být vytvořeny ručně pomocí
RunPython
migrace.
Vyberte si migraci, která vám vyhovuje, a spusťte makemigrations
a pak se ujistěte, že aktualizujete své migrační soubory pokaždé, když aktualizujete svůj model – a to je víceméně vše. To vám umožní uchovávat vaše migrace uložené s vaším kódem v git a zajistit, že můžete aktualizovat strukturu databáze, aniž byste museli ztratit data.
Šťastnou migraci!