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 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 ]\nMożesz również podać podpowiedzi, które zostaną przekazane do metody routera bazy danych allow_migrate() jako **hints:
myapp/dbrouters.pyclass 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\nNastępnie, aby wykorzystać to w swoich migracjach, wykonaj co następuje:
\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.
Do swojego modelu dodaj pole z argumentami``default=uuid.uuid4`` oraz unique=True (wybierz wartość domyślną odpowiednią do typu pola, które dodajesz).
Wykonaj polecenie makemigrations. To powinno wygenerować migrację z operacją ``AddField.
Wygeneruj dwa pliki pustych migracji dla tej samej aplikacji poprzez wykonanie makemigrations myapp --empty dwukrotnie. W poniższym przykładzie zmieniliśmy nazwy plików migracji aby nadać im bardziej zrozumiałe nazwy.
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:
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\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 ]\nZmodyfikuj plik pierwszej migracji. Wygenerowana klasa migracji powinna wyglądać podobnie do tej:
\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. Also add an import\nof uuid. For example:
0005_populate_uuid_values.py# 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 ]\nTeraz możesz zastosować migracje jak zwykle, w poleceniu migrate.
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.
Oto przykład niezatomizowanej migracji danych, która aktualizuje dużą tabelę w mniejszych partiach:
\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 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.
Wartość dependencies jest zadeklarowana jak ta:
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.
Możesz użyć migracji danych w celu przeniesienia danych z jednej aplikacji zewnętrznej do innej.
\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.
Oto prosta migracja:
\nmyapp/migrations/0124_move_old_app_to_new_app.pyfrom 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'))\nAlso consider what you want to happen when the migration is unapplied. You\ncould either do nothing (as in the example above) or remove some or all of the\ndata from the new application. Adjust the second argument of the\nRunPython operation accordingly.
ManyToManyField to use a through modelLink 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 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.
For example, if we had a Book model with a ManyToManyField linking to\nAuthor, we could add a through model AuthorBook with a new field\nis_primary, like so:
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 ]\nIf 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.