データ移行

これは、Django移行シリーズの最後の記事です：

パート1：Djangoの移行-入門書
パート2：移行を深く掘り下げる
パート3：データ移行（現在の記事）
ビデオ：Django1.7の移行-入門書

もう一度。

移行は主にデータベースのデータモデルを最新の状態に保つためのものですが、データベースは単なるデータモデルではありません。最も注目すべきは、それはデータの大規模なコレクションでもあります。したがって、データベースの移行に関する議論は、データの移行についても話さなければ完了しません。

2015年2月12日更新 ：アプリレジストリからモデルを検索するようにデータ移行を変更しました。

定義されたデータ移行

データ移行は、多くのシナリオで使用されます。非常に人気のある2つは次のとおりです。

アプリケーションが正常に動作するために存在することに依存する「システムデータ」をロードする場合。
データモデルを変更すると、既存のデータを変更する必要が生じた場合。

テスト用のダミーデータのロードは上記のリストに含まれていないことに注意してください。移行を使用してそれを行うこともできますが、移行は本番サーバーで実行されることが多いため、本番サーバーで大量のダミーテストデータを作成することはおそらく望ましくありません。

例

以前の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のようにフィクスチャが自動的に読み込まれることはありません。

これは主に哲学によるものです。

移行を使用してデータをロードすることもできますが、それらは主にデータやデータモデルの移行に関するものです。システムデータの読み込みの例を示しました。これは主に、データ移行の設定方法を簡単に説明しているためですが、多くの場合、データ移行は、新しいデータモデルに一致するようにデータを変換するなどのより複雑なアクションに使用されます。

たとえば、1つだけではなく複数の取引所からの価格の保存を開始することにした場合、price_goxのようなフィールドを追加できます。、price_btc 、などの場合、移行を使用してすべてのデータをpriceから移動できます。 price_btcへの列列。

一般に、Django 1.7で移行を処理する場合、データベースの移行とは別の演習としてデータを読み込むことを考えるのが最善です。フィクスチャを引き続き使用/ロードする場合は、次のようなコマンドを使用できます。

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

これにより、フィクスチャからデータベースにデータがロードされます。

これは、データ移行の場合のように自動的には行われませんが（これはおそらく良いことです）、機能は引き続き存在します。紛失していないので、必要に応じて備品を使い続けてください。違いは、必要なときにフィクスチャを使用してデータをロードすることです。これは、単体テストのテストデータをロードするためにフィクスチャを使用している場合に注意する必要があります。

結論

これは、前の2つの記事とともに、移行を使用するときに遭遇する最も一般的なシナリオをカバーしています。シナリオは他にもたくさんあります。興味があり、本当に移行に飛び込みたい場合は、（コード自体を除いて）最適な場所は公式ドキュメントです。

これは最新のものであり、物事がどのように機能するかを説明するのに非常に役立ちます。例を見たいより複雑なシナリオがある場合は、以下にコメントしてお知らせください。

一般的なケースでは、次のいずれかを扱っていることに注意してください。

スキーマの移行： データを変更せずにデータベースまたはテーブルの構造を変更します。これは最も一般的なタイプであり、Djangoは通常これらの移行を自動的に作成できます。
データ移行： データの変更、または新しいデータのロード。 Djangoはこれらを生成できません。 RunPythonを使用して手動で作成する必要があります移行。

したがって、適切な移行を選択し、makemigrationsを実行します。そして、モデルを更新するたびに必ず移行ファイルを更新してください。それは多かれ少なかれそれです。これにより、移行をgitのコードとともに保存し、データを失うことなくデータベース構造を更新できるようになります。

移行をお楽しみください！