本文介绍了如何为可能遇到的不同场景组织和编写数据库迁移。关于迁移的介绍性资料，参考 专题指南。
\n使用多种数据库时，你可能需要指定是否为特定数据库运行迁移。例如，你可能 只想 为特定数据库运行迁移。
\n为此，你可以在 RunPython 操作中检查数据库连接别名，通过查看 schema_editor.connection.alias 属性:
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 ]\n你也能提供会以 **hints 传递给数据库路由器的 allow_migrate() 方法的提示：
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\n然后，要将其在迁移中生效，像下面这样做:
\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 ]\n若你的 RunPython 或 RunSQL 操作只影响了一个模型，为其传入 model_name 作为提示，使其对路由器更加透明。这对可复用的和第三方应用特别重要。
应用 “普通” 迁移，将新的唯一非空的字段添加到已拥有一些行的表格会抛出一个错误，因为用于填充现有行的值只生成一次，从而打破了唯一约束。唯一非空字段即所有行的该字段都不能为空，且值唯一，不能重复。
\n因此，需要做以下步骤。在本例中，我们将添加一个带默认值的非空 UUIDField。根据你的需要修改对应字段。
在模型中以 default=uuid.uuid4 和 unique=True 参数添加该字段（根据字段类型，为其选择一个合适的默认值）。
运行 makemigrations 命令。这将生成一个 AddField 操作的迁移。
通过运行 makemigrations myapp --empty 两次为同一应用生成两个相同的空迁移文件。我们已在以下例子中将迁移文件重命名成有意义的名字。
从自动生成的迁移（3个新文件中的第一个）中将 AddField 操作拷贝至上一个迁移，将 AddField 改为 AlterField，添加 uuid 和 models 的导入。例子：
# 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 ]\n将 unique=True 改为 null=True——这将创建中间 null 字段，并延迟创建唯一性约束，直到我们已为所以行填充了唯一值。
在第一个空的迁移文件中，添加一个 RunPython 或 RunSQL 操作，为每个已存在的行创建一个唯一值（本例中 UUID）。同时添加 uuid 的导入。例子：
# 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 ]\n现在你能像往常一样用 migrate 应用迁移了。
注意，若你允许运行迁移时创建对象可能会造成竞争。 AddField 后和 RunPython 前创建的对象保留原先重写的 uuid 值。
对于支持 DDL 事务的数据库 (SQLite and PostgreSQL)，迁移默认运行在事务内。对于类似在大数据表上运行数据迁移的场景，你可以通过将 atomic 属性置为 False 避免在事务中运行迁移:
from django.db import migrations\n\nclass Migration(migrations.Migration):\n atomic = False\n在这样的迁移种，所有的操作运行时都不含事务。通过使用 atomic() 或为 RunPython 传入 atomic=True 能将部分迁移置于事务之中。
这是一个例子，关于非原子性数据迁移操作，将更新大数据表的操作分为数个小批次:
\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 ]\natomic 属性对不支持 DDL 事务的数据库没有影响（例如 MySQL，Oracle）。（MySQL 的 原子性 DDL 语句支持 指向独立的语句，而不是封装在能回滚的事务中的多句语句。）
Django 不是通过迁移的名字决定迁移执行顺序，而是通过在 迁移 类上使用两个属性： dependencies 和 run_before。
若你用过 makemigrations 命令，你可能早已在运行时见过 dependencies，因为自动创建的迁移将此定义为其创建过程的一部分。
依赖 属性像这样申明:
from django.db import migrations\n\nclass Migration(migrations.Migration):\n\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，前者在旧应用程序中检索模型。这种方法允许你在任何地方部署项目，而无需先安装并且卸载旧应用程序。
这是一个迁移示例：
\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 操作的第二个参数。
through 模型来更改 ManyToManyField 字段。Link to this heading#假如你通过使用 through 模型来改变 ManyToManyField ，默认的迁移操作会删除现存的表并创建一个新的表，来解耦现存的关联。为了避免这种情况，你可以使用 SeparateDatabaseAndState 来重命名现存的表为另一个新的表名，同时告诉迁移自动探测器新的模型已经被建立了。你可以通过 sqlmigrate 或 dbshell 来查看现有的表名。你可以通过模型的 _meta.db_table 属性来检查新的表名。新的 through 模型应该使用与那些 外键 们相同的名称。同时，假如需要其他额外的字段，它们应该添加在 SeparateDatabaseAndState 操作之后。
例如，假如你有一个 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 ),\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 的修改操作不会被执行。