This document explains how to structure and write database migrations for\ndifferent scenarios you might encounter. For introductory material on\nmigrations, see the topic guide.
\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 not 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:
myapp/dbrouters.pyclass MyRouter(object):\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 and change AddField to\nAlterField. For example:
0006_remove_uuid_null.py# -*- coding: utf-8 -*-\nfrom __future__ import unicode_literals\n\nfrom django.db import migrations, models\nimport uuid\n\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 ]\nEdit the first migration file. The generated migration class should look\nsimilar to this:
\n0004_add_uuid_field.pyclass 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. For example:
0005_populate_uuid_values.py# -*- coding: utf-8 -*-\nfrom __future__ import unicode_literals\n\nfrom django.db import migrations, models\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()\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.
Django determines the order in which migrations should be applied not by the\nfilename of each migration, but by building a graph using two properties on the\nMigration class: dependencies and run_before.
If you’ve used the makemigrations command you’ve probably\nalready seen dependencies in action because auto-created\nmigrations have this defined as part of their creation process.
The dependencies property is declared like this:
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.
To achieve this, place all migrations that should depend on yours in\nthe run_before attribute on your Migration class:
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.