Database Migrations
Database migrations adalah perubahan terstruktur yang menerapkan evolusi schema database secara bertahap. Bentuknya dapat berupa SQL atau operasi deklaratif framework, bukan hanya script SQL manual. Django memisahkan pembuatan migration files dari penerapannya ke database.
Migrasi membantu membuat perubahan terkendali dan dapat direproduksi, tetapi tidak otomatis menjamin integritas data, kesamaan environment, atau zero downtime. Hasil tetap bergantung pada keadaan awal, isi data, operasi, dan perilaku database yang digunakan.
Apa yang berubah
Schema migration dapat membuat, mengubah, atau menghapus tabel, kolom, index, dan foreign key. Data migration mengubah isi atau representasi record, misalnya mengisi kolom baru dari data lama. Flyway mencakup perubahan struktur, reference data, dan koreksi user data; Django menyediakan RunPython untuk transformasi data yang tidak dihasilkan otomatis seperti schema migration.
Relational Databases menjelaskan struktur dan constraints yang diubah. Database constraints enforce shared invariants at the write boundary menjelaskan aturan yang perlu tetap berlaku setelah perubahan, bukan jaminan yang muncul hanya karena migration file tersedia.
Riwayat, urutan, dan pengulangan
Migration files disimpan bersama source code dan diterapkan ke environment tujuan. Django mengurutkan migrasi berdasarkan dependencies, termasuk antar-app; nomor filename saja bukan penentu universal.
Pada Flyway versioned migrations, setiap migrasi memiliki version unik, description, dan checksum. Schema history mencatat yang sudah diterapkan. Sesudah mencapai permanent downstream environment, koreksi dilakukan melalui migrasi baru. Applied migrations preserve history when corrections move forward menjelaskan alasan menghindari perubahan diam-diam terhadap riwayat bersama.
Repeatable process tidak berarti semua script idempotent. Flyway repeatable migrations dijalankan ulang ketika checksum berubah, setelah pending versioned migrations; penulis bertanggung jawab memastikan operasi aman diulang. Aturan ini khusus Flyway, bukan sifat semua migration tools.
Rollout yang kompatibel
Expand and contract memisahkan penambahan struktur dari penghapusan struktur lama:
- Tambahkan struktur baru tanpa memutus client lama, termasuk default atau nullability yang sesuai.
- Sesuaikan penulisan agar perubahan baru tidak tertinggal selama perpindahan data; panduan mencontohkan penulisan ke kedua struktur.
- Migrasikan data lama dengan menjaga maknanya, lalu uji query dan perilaku baru.
- Alihkan pembacaan, hentikan penulisan lama setelah verifikasi, dan hapus struktur lama ketika seluruh client telah berpindah.
Urutan perubahan client dan perpindahan data perlu disesuaikan dengan desain, bukan disalin sebagai resep universal. Schema changes need compatibility until old clients retire menghubungkan proses ini dengan Deployment: sukses menjalankan DDL belum membuktikan semua versi aplikasi tetap bekerja.
Transaksi, rollback, dan lock
Tiga hal berbeda perlu dipisahkan: rollback transaksi yang belum commit, migrasi balik setelah perubahan diterapkan, dan rollback artifact aplikasi. Django 5.2 menggunakan satu transaksi per migrasi secara default pada backend yang mendukung DDL transactions, seperti PostgreSQL dan SQLite; MySQL tidak memberi dukungan transaksi schema alteration yang sama. Operasi irreversible juga dapat membuat migrasi tidak dapat dibalik.
Database transactions keep dependent writes from becoming partial outcomes tetap berlaku dalam transaction boundary yang didukung. Ia bukan janji bahwa semua DDL atau seluruh deployment dapat dibatalkan bersama. Prisma Data Guide juga memperingatkan bahwa data yang hanya dapat direpresentasikan schema baru dapat hilang atau memerlukan pekerjaan tambahan ketika kembali ke schema lama.
PostgreSQL 18 ALTER TABLE umumnya memperoleh ACCESS EXCLUSIVE lock kecuali subform menyatakan lain. Sebagian perubahan menyebabkan table rewrite. Untuk constraints yang mendukungnya, NOT VALID menunda pemeriksaan baris lama dan VALIDATE CONSTRAINT memeriksanya kemudian dengan lock lebih ringan; ini bukan penghapusan seluruh lock.
Pemeriksaan sebelum produksi
Sebagai checklist operasional yang disintesis dari Django, Prisma migration guide, dan expand-contract:
- Review operasi yang dihasilkan dan dependencies sebelum penerapan.
- Uji pada salinan data produksi yang dilindungi sesuai sensitivitasnya, bukan hanya database kosong.
- Periksa hasil transformasi, kompatibilitas client lama dan baru, serta dampak lock dan durasi.
- Siapkan backup dan jalur pemulihan; tentukan apakah kegagalan memerlukan rollback, koreksi forward, atau restore.
- Pantau error dan perilaku aplikasi setelah deployment sebelum menghapus struktur lama.