Dokumen ini menjelaskan bagaimana menyusun dan menulis perpindahan basisdata untuk skenario berbeda anda mungkin hadapi. Untuk bahan perkenalan pada perpindahan, lihat the topic guide.
\nKetika menggunakan banyak basisdata, anda mungkin butuh memahami apakat atau tidak menjalankan perpindahan terhadap basisdata tertentu. Sebagai contoh, anda ingin hanya menjalankan perpindahan pada basisdata tertentu.
\nUntuk melakukan itu anda dapat memeriksa nama lain hubungan basisdata didalam operasi RunPython dengan mencari atribut 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 ]\nAnda dapat juga menyediakan bayangan yang akan dilewatkan ke cara allow_migrate() dari router basisdata sebagai **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\nKemudian, untuk mempengaruhi ini dalam pemindahan anda, lakukan berikut:
\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 ]\nJika operasi RunPython atau RunSQL anda hanya berpengaruh pada satu model, adalah latihan bagus untuk melewatkan model_name sebagai sebuah bayangan untuk membuatnya se transparan mungkin ke router. Ini khususnya penting untuk aplikasi digunakan kembali dan pihak ketiga.
Memberlakukan perpindahan "plain" yang menambahkan bidang bukan null unik ke sebuah tabel dengan baris yang ada akan menampilkan sebuah kesalahan karena nilai digunakan untuk mengumpulkan baris-baris yang ada dibangkitkan hanya sekali, demikian merusak pembatas unik.
\nKarena itu, langkah-langkah berikut harus diambil. Dalam contoh ini, kami akan menambahkan UUIDField bukan null dengan nilai awal. Rubah bidang masing-masing menurut kebutuhan anda.
Tambah bidang pada model anda dengan argumen default=uuid.uuid4 dan unique=True (pilih awal yang sesuai untuk jenis dari bidang anda sedang tambahkan).
Jalankan perintah makemigrations. Ini harus membangkitkan perpindahan dengan tindakan AddField.
Bangkitkan dua berkas-berkas perpindahan kosong untuk aplikasi sama dengan menjalankan makemigrations myapp --empty dua kali. Kami telah menamai kembali berkas-berkas perpindahan untuk memberikan mereka nama berarti di contoh dibawah.
Salin operasi AddField dari perpindahan dibangkitkan otomatis (pertama dari tiga berkas-berkas baru) ke perpindahan terakhir, rubah AddField ke AlterField, dan impor dari uuid dan models. Sebagai contoh:
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 ]\nSunting berkas perpindahan pertama. Kelas perpindahan dibangkitkan harus kelihatan mirip seperti ini:
\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 ]\nRubah unique=True menjadi null=True -- ini akan membuat perantara bidang null dan menunda pembuatan pembatas unik sampai kami telah mengumpulkan nilai-nilai unik pada semua baris.
Dalam berkas perpindahan kosong pertama, tambah sebuah tindakan RunPython atau RunSQL untuk membangkitkan nilai unik (UUID dalam contoh) untuk setiap baris yang yang ada. Juga tambah sebuah impor dari uuid. Sebagai contoh:
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 ]\nSekarang anda dapat berlakukan perpindahan seperti biasa dengan perintah migrate
Catat ada kondisi jarang jika anda mengizinkan obyek untuk dibuat selagi perpindahan ini berjalan. Obyek dibuat setelah AddField dan sebelum RunPython akan mempunyai uuid asli mereka ditulis kembali.
Pada basisdata yang mendukung transaksi DDL (SQLite dan PostgreSQL), perpindahan akan berjalan di dalam sebuah transaksi secara awal. Untuk penggunakan kasus seperti melakukan perpindahan data pada tabel-tabel besar, anda mungkin ingin mencegah perpindahan dari berjalan dalam sebuah transaksi dengan mengatur atribut atomic menjadi False:
from django.db import migrations\n\nclass Migration(migrations.Migration):\n atomic = False\nDalam perpindahan seperti itu, semua tindakan berjalan tanpa sebuah transaksi. Itu memungkinkan menjalankan bagian-bagian dari perpindahan didalam sebuah transaksi menggunakan atomic() atau dengan melewatkan atomic=True ke RunPython.
Ini adalah sebuah contoh dari perpindahan data non-atomic yang memperbaharui tabel besar dalam kumpulan-kumpulan kecil:
\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 ]\nAtribut atomic tidak mempunyai pengaruh pada basisdata yang tidak mendukung transaksi DDL (yaitu MySQL, Oracle). (atomic DDL statement support MySQL mengacu pada pernyataan masing-masing daripada banyak pernyataan dibungkus dalam sebuah transaksi yang dapat di kembalikan.)
Django menentukan urutan dalam perpindahan mana harus diberlakukan tidak berdasarkan nama berkas dari setiap perpindahan, tetapi dengan membangun sebuah grafik menggunakan dua alat pada kelas Migration: dependencies dan run_before.
Jika anda telah menggunakan perintah makemigrations anda mungkin seudah melihat dependencies dalam tindakan karena perpindahan dibuat-otomatis mempunyai penentuan ini sebagai bagian dari pengolahan pembuatan mereka.
Properti dependencies diumumkan seperti ini:
from django.db import migrations\n\nclass Migration(migrations.Migration):\n\n dependencies = [\n ('myapp', '0123_the_previous_migration'),\n ]\nBiasanya ini akan cukup, tetapi dari waktu ke waktu anda mungkin butuh memastikan bahwa perpindahan anda berjalan sebelum perpindahan lain. Ini berguna, sebagai contoh, untuk membuat perpindahan aplikasi pihak ketiga berjalan setelah pergantian AUTH_USER_MODEL anda.
Untuk mencapai ini, tempatkan semua perpindahan yang harus tergantung pada diri anda dalam atribut run_before pada kelas Migration anda.
class Migration(migrations.Migration):\n ...\n\n run_before = [\n ('third_party_app', '0001_do_awesome'),\n ]\nLebih suka menggunakan dependencies daripada run_before ketika memungkinkan. Anda harus hanya menggunakan run_before jika dia tidak diinginkan atau tidak praktis untuk menentukan dependencies dalam perpindahan yang anda ingin jalankan setelah satu anda sedang tulis.
Anda dapat menggunakan perpindahan data untuk memindahkan data dari satu aplikasi pihak-ketiga ke lainnya.
\nJika anda berencana memindahkan aplikasi lama nanti, anda akan butuh menyetel properti dependencies berdasarkan pada apakah atau tidak aplikasi lama terpasang. Jika tidak, anda akan kehilangan ketergantungan sekali anda melepas aplikasi lama. Sama halnya, anda akan butuh menangkap LookupError di panggilan apps.get_model() yang mengambil model-model dari aplikasi lama. Pendekatan ini mengizinkan anda menyebarkan proyek anda dimanapun tanpa memasang dan melepas aplikasi lama terlebih dahulu.
Ini adalah contoh perpindahan:
\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'))\nJuga pertimbangkan apa anda inginkan terjadi ketika perpindahan tidak diberlakukan. Anda dapat juga tidak melakukan apapun (seperti di contoh diatas) atau memindahkan beberapa atau semua data dari apliaksi baru. Sesuaikan argumen kedua dari operasi RunPython sesuai dengan itu.
ManyToManyField untuk menggunakan 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.
Sebagai contoh, jika kita memiliki model Book dengan ManyToManyField yang mengarah ke Author, kita bisa menambahkan model antara AuthorBook dengan field baru is_primary, seperti ini:
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 ]\nJika anda ingin merubah sebuah model tidak dikendalikan (managed=False) menjadi dikendalikan, anda harus memindahkan managed=False dan bangkitkan perpindahan sebelum membuat perubahan skema-terhubung lainnya ke model, sejak perubahan skema yang muncul di perpindahan yang mengandung tindakan untuk merubah Meta.managed mungkin tidak diberlakukan.