本文介绍了如何为可能遇到的不同场景组织和编写数据库迁移。关于迁移的介绍性资料，参考 专题指南。
\n使用多种数据库时，你可能需要指定是否为特定数据库运行迁移。例如，你可能 只想 为特定数据库运行迁移。
\n为此，你可以在 RunPython 操作中检查数据库连接别名，通过查看 schema_editor.connection.alias 属性:
from django.db import migrations\n\n\ndef forwards(apps, schema_editor):\n if schema_editor.connection.alias != "default":\n return\n # Your migration code goes here\n\n\nclass Migration(migrations.Migration):\n dependencies = [\n # Dependencies to other migrations\n ]\n\n operations = [\n migrations.RunPython(forwards),\n ]\n你也能提供会以 **hints 传递给数据库路由器的 allow_migrate() 方法的提示：
myapp/dbrouters.pyclass MyRouter:\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\n然后，要将其在迁移中生效，像下面这样做:
\nfrom django.db import migrations\n\n\ndef forwards(apps, schema_editor):\n # Your migration code goes here\n ...\n\n\nclass Migration(migrations.Migration):\n dependencies = [\n # Dependencies to other migrations\n ]\n\n operations = [\n migrations.RunPython(forwards, hints={"target_db": "default"}),\n ]\n若你的 RunPython 或 RunSQL 操作只影响了一个模型，为其传入 model_name 作为提示，使其对路由器更加透明。这对可复用的和第三方应用特别重要。
应用 “普通” 迁移，将新的唯一非空的字段添加到已拥有一些行的表格会抛出一个错误，因为用于填充现有行的值只生成一次，从而打破了唯一约束。唯一非空字段即所有行的该字段都不能为空，且值唯一，不能重复。
\n因此，需要做以下步骤。在本例中，我们将添加一个带默认值的非空 UUIDField。根据你的需要修改对应字段。
在模型中以 default=uuid.uuid4 和 unique=True 参数添加该字段（根据字段类型，为其选择一个合适的默认值）。
运行 makemigrations 命令。这将生成一个 AddField 操作的迁移。
通过运行 makemigrations myapp --empty 两次为同一应用生成两个相同的空迁移文件。我们已在以下例子中将迁移文件重命名成有意义的名字。
从自动生成的迁移（3个新文件中的第一个）中将 AddField 操作拷贝至上一个迁移，将 AddField 改为 AlterField，添加 uuid 和 models 的导入。例子：
0006_remove_uuid_null.py# Generated by Django A.B on YYYY-MM-DD HH:MM\nfrom django.db import migrations, models\nimport uuid\n\n\nclass Migration(migrations.Migration):\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编辑第一个迁移文件。生成的迁移类应该看起来像这样：
\n0004_add_uuid_field.pyclass Migration(migrations.Migration):\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 ]\n将 unique=True 改为 null=True——这将创建中间 null 字段，并延迟创建唯一性约束，直到我们已为所以行填充了唯一值。
在第一个空的迁移文件中，添加一个 RunPython 或 RunSQL 操作，为每个已存在的行创建一个唯一值（本例中 UUID）。同时添加 uuid 的导入。例子：
0005_populate_uuid_values.py# Generated by Django A.B on YYYY-MM-DD HH:MM\nfrom django.db import migrations\nimport uuid\n\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\n\nclass Migration(migrations.Migration):\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 ]\n现在你能像往常一样用 migrate 应用迁移了。
注意，若你允许运行迁移时创建对象可能会造成竞争。 AddField 后和 RunPython 前创建的对象保留原先重写的 uuid 值。
对于支持 DDL 事务的数据库 (SQLite and PostgreSQL)，迁移默认运行在事务内。对于类似在大数据表上运行数据迁移的场景，你可以通过将 atomic 属性置为 False 避免在事务中运行迁移:
from django.db import migrations\n\n\nclass Migration(migrations.Migration):\n atomic = False\n在这样的迁移种，所有的操作运行时都不含事务。通过使用 atomic() 或为 RunPython 传入 atomic=True 能将部分迁移置于事务之中。
这是一个例子，关于非原子性数据迁移操作，将更新大数据表的操作分为数个小批次:
\nimport uuid\n\nfrom django.db import migrations, transaction\n\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\n\nclass Migration(migrations.Migration):\n atomic = False\n\n operations = [\n migrations.RunPython(gen_uuid),\n ]\natomic 属性对不支持 DDL 事务的数据库没有影响（例如 MySQL，Oracle）。（MySQL 的 原子性 DDL 语句支持 指向独立的语句，而不是封装在能回滚的事务中的多句语句。）
Django 不是通过迁移的名字决定迁移执行顺序，而是通过在 迁移 类上使用两个属性： dependencies 和 run_before。
若你用过 makemigrations 命令，你可能早已在运行时见过 dependencies，因为自动创建的迁移将此定义为其创建过程的一部分。
依赖 属性像这样申明:
from django.db import migrations\n\n\nclass Migration(migrations.Migration):\n dependencies = [\n ("myapp", "0123_the_previous_migration"),\n ]\n通常这就够用了，但是有很多次，你总是需要确认你的迁移运行在其它迁移 之前。例如，这对于让第三方应用的迁移运行在替换 AUTH_USER_MODEL 之后就很有用。
要实现此目的，将所有需要先运行的迁移置于你的 Migration 类的 run_before 属性:
class Migration(migrations.Migration):\n ...\n\n run_before = [\n ("third_party_app", "0001_do_awesome"),\n ]\n尽可能使用 dependencies，而不是 run_before。只有在在特定迁移中添加 dependencies 使其运行于你编写的迁移之后是没希望的和不切实际的情况下，你才能使用 run_before。
你可以使用数据迁移把数据从一个第三方应用程序中转移到另一个。
\n如果你计划要移除旧应用程序，则需要根据是否安装旧应用程序来设置 依赖 属性。否则，一旦你卸载旧应用程序，就会缺失依赖项。同样，你需要在调用 app.get_model() 时捕获 LookupError，前者在旧应用程序中检索模型。这种方法允许你在任何地方部署项目，而无需先安装并且卸载旧应用程序。
这是一个迁移示例：
\nmyapp/migrations/0124_move_old_app_to_new_app.pyfrom django.apps import apps as global_apps\nfrom django.db import migrations\n\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\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 操作的第二个参数。
through 模型来更改 ManyToManyField 字段。Link to this heading#If you change a ManyToManyField to use a through\nmodel, the default migration will delete the existing table and create a new\none, losing the existing relations. To avoid this, you can use\nSeparateDatabaseAndState to rename the existing table to the new\ntable name while telling the migration autodetector that the new model has\nbeen created. You can check the existing table name and constraint name through\nsqlmigrate or dbshell. You can check the new table name\nwith the through model's _meta.db_table property. Your new through\nmodel should use the same names for the ForeignKeys as Django did. Also if\nit needs any extra fields, they should be added in operations after\nSeparateDatabaseAndState.
例如，假如你有一个 Book 模型，它通过 ManyToManyField 链接 Author 模型，我们可以通过像下面这样添加一个带有新字段 is_primary 的中间模型 AuthorBook
from django.db import migrations, models\nimport django.db.models.deletion\n\n\nclass Migration(migrations.Migration):\n dependencies = [\n ("core", "0001_initial"),\n ]\n\n operations = [\n migrations.SeparateDatabaseAndState(\n database_operations=[\n # Old table name from checking with sqlmigrate, new table\n # name from AuthorBook._meta.db_table.\n migrations.RunSQL(\n sql="ALTER TABLE core_book_authors RENAME TO core_authorbook",\n reverse_sql="ALTER TABLE core_authorbook RENAME TO core_book_authors",\n ),\n ],\n state_operations=[\n migrations.CreateModel(\n name="AuthorBook",\n fields=[\n (\n "id",\n models.AutoField(\n auto_created=True,\n primary_key=True,\n serialize=False,\n verbose_name="ID",\n ),\n ),\n (\n "author",\n models.ForeignKey(\n on_delete=django.db.models.deletion.DO_NOTHING,\n to="core.Author",\n ),\n ),\n (\n "book",\n models.ForeignKey(\n on_delete=django.db.models.deletion.DO_NOTHING,\n to="core.Book",\n ),\n ),\n ],\n options={\n "constraints": [\n models.UniqueConstraint(\n fields=["author", "book"],\n name="unique_author_book",\n )\n ],\n },\n ),\n migrations.AlterField(\n model_name="book",\n name="authors",\n field=models.ManyToManyField(\n to="core.Author",\n through="core.AuthorBook",\n ),\n ),\n ],\n ),\n migrations.AddField(\n model_name="authorbook",\n name="is_primary",\n field=models.BooleanField(default=False),\n ),\n ]\n如果你想要将非托管模型 (managed=False) 变为托管的，你必须移除 managed=False 并且在对此模型做其他模式相关的改变前生成一次迁移，因为如果迁移中出现模式改变，对 Meta.managed 的修改操作不会被执行。