このドキュメントでは、遭遇する可能性のあるいくつかのシナリオに対する、データベースのマイグレーションの構成方法と書き方について説明します。マイグレーションに関する入門的な資料を探しているなら、トピック別ガイド を読んでください。
\nWhen using multiple databases, you may need to figure out whether or not to\nrun a migration against a particular database. For example, you may want to\nonly run a migration on a particular database.
\nIn order to do that you can check the database connection's alias inside a\nRunPython operation by looking at the schema_editor.connection.alias\nattribute:
from django.db import migrations\n\ndef forwards(apps, schema_editor):\n if schema_editor.connection.alias != 'default':\n return\n # Your migration code goes here\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n # Dependencies to other migrations\n ]\n\n operations = [\n migrations.RunPython(forwards),\n ]\nYou can also provide hints that will be passed to the allow_migrate()\nmethod of database routers as **hints:
class MyRouter:\n\n def allow_migrate(self, db, app_label, model_name=None, **hints):\n if 'target_db' in hints:\n return db == hints['target_db']\n return True\nThen, to leverage this in your migrations, do the following:
\nfrom django.db import migrations\n\ndef forwards(apps, schema_editor):\n # Your migration code goes here\n ...\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n # Dependencies to other migrations\n ]\n\n operations = [\n migrations.RunPython(forwards, hints={'target_db': 'default'}),\n ]\nIf your RunPython or RunSQL operation only affects one model, it's good\npractice to pass model_name as a hint to make it as transparent as possible\nto the router. This is especially important for reusable and third-party apps.
Applying a "plain" migration that adds a unique non-nullable field to a table\nwith existing rows will raise an error because the value used to populate\nexisting rows is generated only once, thus breaking the unique constraint.
\nTherefore, the following steps should be taken. In this example, we'll add a\nnon-nullable UUIDField with a default value. Modify\nthe respective field according to your needs.
Add the field on your model with default=uuid.uuid4 and unique=True\narguments (choose an appropriate default for the type of the field you're\nadding).
Run the makemigrations command. This should generate a migration\nwith an AddField operation.
Generate two empty migration files for the same app by running\nmakemigrations myapp --empty twice. We've renamed the migration files to\ngive them meaningful names in the examples below.
Copy the AddField operation from the auto-generated migration (the first\nof the three new files) to the last migration, change AddField to\nAlterField, and add imports of uuid and models. For example:
# Generated by Django A.B on YYYY-MM-DD HH:MM\nfrom django.db import migrations, models\nimport uuid\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n ('myapp', '0005_populate_uuid_values'),\n ]\n\n operations = [\n migrations.AlterField(\n model_name='mymodel',\n name='uuid',\n field=models.UUIDField(default=uuid.uuid4, unique=True),\n ),\n ]\n最初の移行ファイルを編集します。 生成された移行クラスは次のようになります:
\nclass Migration(migrations.Migration):\n\n dependencies = [\n ('myapp', '0003_auto_20150129_1705'),\n ]\n\n operations = [\n migrations.AddField(\n model_name='mymodel',\n name='uuid',\n field=models.UUIDField(default=uuid.uuid4, unique=True),\n ),\n ]\nChange unique=True to null=True -- this will create the intermediary\nnull field and defer creating the unique constraint until we've populated\nunique values on all the rows.
In the first empty migration file, add a\nRunPython or\nRunSQL operation to generate a\nunique value (UUID in the example) for each existing row. Also add an import\nof uuid. For example:
# Generated by Django A.B on YYYY-MM-DD HH:MM\nfrom django.db import migrations\nimport uuid\n\ndef gen_uuid(apps, schema_editor):\n MyModel = apps.get_model('myapp', 'MyModel')\n for row in MyModel.objects.all():\n row.uuid = uuid.uuid4()\n row.save(update_fields=['uuid'])\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n ('myapp', '0004_add_uuid_field'),\n ]\n\n operations = [\n # omit reverse_code=... if you don't want the migration to be reversible.\n migrations.RunPython(gen_uuid, reverse_code=migrations.RunPython.noop),\n ]\nNow you can apply the migrations as usual with the migrate command.
Note there is a race condition if you allow objects to be created while this\nmigration is running. Objects created after the AddField and before\nRunPython will have their original uuid’s overwritten.
On databases that support DDL transactions (SQLite and PostgreSQL), migrations\nwill run inside a transaction by default. For use cases such as performing data\nmigrations on large tables, you may want to prevent a migration from running in\na transaction by setting the atomic attribute to False:
from django.db import migrations\n\nclass Migration(migrations.Migration):\n atomic = False\nWithin such a migration, all operations are run without a transaction. It's\npossible to execute parts of the migration inside a transaction using\natomic() or by passing atomic=True to\nRunPython.
以下は、小さなバッチで大きなテーブルを更新する非原子データ移行の例です:
\nimport uuid\n\nfrom django.db import migrations, transaction\n\ndef gen_uuid(apps, schema_editor):\n MyModel = apps.get_model('myapp', 'MyModel')\n while MyModel.objects.filter(uuid__isnull=True).exists():\n with transaction.atomic():\n for row in MyModel.objects.filter(uuid__isnull=True)[:1000]:\n row.uuid = uuid.uuid4()\n row.save()\n\nclass Migration(migrations.Migration):\n atomic = False\n\n operations = [\n migrations.RunPython(gen_uuid),\n ]\nThe atomic attribute doesn't have an effect on databases that don't support\nDDL transactions (e.g. MySQL, Oracle). (MySQL's atomic DDL statement support refers to individual\nstatements rather than multiple statements wrapped in a transaction that can be\nrolled back.)
Djangoは各移行のファイル名ではなく、Migration クラスの2つのプロパティ、dependencies と run_before を使用してグラフを作成することで、移行を適用する順序を決定します。
makemigrations コマンドを使用した場合、自動作成された移行では作成プロセスの一部としてこれが定義されているため、おそらく dependencies が動作しているのを既に見ているでしょう。
dependencies プロパティは次のように宣言されます:
from django.db import migrations\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n ('myapp', '0123_the_previous_migration'),\n ]\nUsually this will be enough, but from time to time you may need to\nensure that your migration runs before other migrations. This is\nuseful, for example, to make third-party apps' migrations run after\nyour AUTH_USER_MODEL replacement.
これを達成するために、あなたの Migration クラスの run_before 属性に依存する必要があるすべてのマイグレーションを配置します:
class Migration(migrations.Migration):\n ...\n\n run_before = [\n ('third_party_app', '0001_do_awesome'),\n ]\nPrefer using dependencies over run_before when possible. You should\nonly use run_before if it is undesirable or impractical to specify\ndependencies in the migration which you want to run after the one you are\nwriting.
データの移行を使用して、あるサードパーティアプリケーションから別のアプリケーションにデータを移動できます。
\nIf you plan to remove the old app later, you'll need to set the dependencies\nproperty based on whether or not the old app is installed. Otherwise, you'll\nhave missing dependencies once you uninstall the old app. Similarly, you'll\nneed to catch LookupError in the apps.get_model() call that\nretrieves models from the old app. This approach allows you to deploy your\nproject anywhere without first installing and then uninstalling the old app.
簡単な移行例を見てみましょう:
\nfrom django.apps import apps as global_apps\nfrom django.db import migrations\n\ndef forwards(apps, schema_editor):\n try:\n OldModel = apps.get_model('old_app', 'OldModel')\n except LookupError:\n # The old app isn't installed.\n return\n\n NewModel = apps.get_model('new_app', 'NewModel')\n NewModel.objects.bulk_create(\n NewModel(new_attribute=old_object.old_attribute)\n for old_object in OldModel.objects.all()\n )\n\nclass Migration(migrations.Migration):\n operations = [\n migrations.RunPython(forwards, migrations.RunPython.noop),\n ]\n dependencies = [\n ('myapp', '0123_the_previous_migration'),\n ('new_app', '0001_initial'),\n ]\n\n if global_apps.is_installed('old_app'):\n dependencies.append(('old_app', '0001_initial'))\nまた、移行が適用されていない場合に何をしたいかを検討します。（上記の例のように）何もしないか、新しいアプリケーションからデータの一部またはすべてを削除することができます。 それに応じて RunPython 操作の2番目の引数を調整します。
If you want to change an unmanaged model (managed=False) to managed, you must remove\nmanaged=False and generate a migration before making other schema-related\nchanges to the model, since schema changes that appear in the migration that\ncontains the operation to change Meta.managed may not be applied.