Migrasi Code First dengan basis data yang sudah ada

Nota

EF4.3 Onwards Only - Fitur, API, dll. yang dibahas di halaman ini diperkenalkan dalam Entity Framework 4.1. Jika Anda menggunakan versi yang lebih lama, beberapa atau semua informasi tidak berlaku.

Artikel ini membahas penggunaan Migrasi Pertama Kode dengan database yang sudah ada, yang tidak dibuat oleh Kerangka Kerja Entitas.

Nota

Artikel ini mengasumsikan Anda tahu cara menggunakan Migrasi Pertama Kode dalam skenario dasar. Jika tidak, maka Anda harus membaca Code First Migrations sebelum melanjutkan.

Langkah 1: Membuat model

Langkah pertama Anda adalah membuat model Code First yang menargetkan database Anda yang sudah ada. Topik Kode Pertama ke Database yang Sudah Ada menyediakan panduan terperinci tentang cara melakukan ini.

Nota

Penting untuk mengikuti langkah-langkah lainnya dalam topik ini sebelum membuat perubahan apa pun pada model Anda yang akan memerlukan perubahan pada skema database. Langkah-langkah berikut mengharuskan model sinkron dengan skema database.

Langkah 2: Aktifkan Migrasi

Langkah selanjutnya adalah mengaktifkan migrasi. Anda dapat melakukan ini dengan menjalankan perintah Enable-Migrations di Package Manager Console.

Perintah ini akan membuat folder dalam solusi Anda yang disebut Migrasi, dan menempatkan satu kelas di dalamnya yang disebut Konfigurasi. Kelas Konfigurasi adalah tempat Anda mengonfigurasi migrasi untuk aplikasi, Anda dapat mengetahui lebih lanjut tentang hal itu dalam topik Migrasi Pertama Kode .

Langkah 3: Menambahkan migrasi awal

Setelah migrasi dibuat dan diterapkan ke database lokal, Anda mungkin juga ingin menerapkan perubahan ini ke database lain. Misalnya, database lokal Anda mungkin merupakan database pengujian dan Pada akhirnya Anda mungkin juga ingin menerapkan perubahan pada database produksi dan/atau database pengujian pengembang lainnya. Ada dua opsi untuk langkah ini dan yang harus Anda pilih tergantung apakah skema database lain kosong atau saat ini cocok dengan skema database lokal.

• Opsi Satu: Gunakan skema yang ada sebagai titik awal. Anda harus menggunakan pendekatan ini ketika database lain yang akan diterapkan migrasi di masa mendatang akan memiliki skema yang sama dengan database lokal Anda saat ini. Misalnya, Anda dapat menggunakan ini jika database pengujian lokal Anda saat ini cocok dengan v1 database produksi Anda dan Anda nantinya akan menerapkan migrasi ini untuk memperbarui database produksi Anda ke v2.
• Opsi Dua: Gunakan database kosong sebagai titik awal. Anda harus menggunakan pendekatan ini ketika database lain yang akan diterapkan migrasi di masa mendatang kosong (atau belum ada). Misalnya, Anda dapat menggunakan ini jika Anda mulai mengembangkan aplikasi menggunakan database pengujian tetapi tanpa menggunakan migrasi dan Anda nantinya ingin membuat database produksi dari awal.

Opsi Satu: Gunakan skema yang ada sebagai titik awal

Migrasi Pertama Kode menggunakan rekam jepret model yang disimpan dalam migrasi terbaru untuk mendeteksi perubahan pada model (Anda dapat menemukan informasi terperinci tentang ini di Migrasi Pertama Kode di Lingkungan Tim). Karena kita akan berasumsi bahwa database sudah memiliki skema model saat ini, kita akan menghasilkan migrasi kosong (no-op) yang memiliki model saat ini sebagai rekam jepret.

1. Jalankan perintah Add-Migration InitialCreate –IgnoreChanges di Package Manager Console. Ini membuat migrasi kosong dengan model saat ini sebagai cuplikan.
2. Jalankan perintah Update-Database di Package Manager Console. Ini akan menerapkan migrasi InitialCreate ke database. Karena migrasi aktual tidak berisi perubahan apa pun, migrasi hanya akan menambahkan baris ke tabel __MigrationsHistory yang menunjukkan bahwa migrasi ini telah diterapkan.

Opsi Dua: Gunakan database kosong sebagai titik awal

Dalam skenario ini, kita memerlukan Migrasi untuk dapat membuat seluruh database dari awal - termasuk tabel yang sudah ada di database lokal kami. Kita akan membuat migrasi InitialCreate yang menyertakan logika untuk membuat skema yang ada. Kami kemudian akan membuat database yang ada terlihat seperti migrasi ini telah diterapkan.

1. Jalankan perintah Add-Migration InitialCreate di Package Manager Console. Ini membuat migrasi untuk membuat skema yang ada.
2. Komentari semua kode dalam metode Up dari migrasi yang baru dibuat. Ini akan memungkinkan kita untuk 'menerapkan' migrasi ke database lokal tanpa mencoba membuat ulang semua tabel dll. yang sudah ada.
3. Jalankan perintah Update-Database di Package Manager Console. Ini akan menerapkan migrasi InitialCreate ke database. Karena migrasi aktual tidak berisi perubahan apa pun (karena kami sementara mengomentarinya), migrasi hanya akan menambahkan baris ke tabel __MigrationsHistory yang menunjukkan bahwa migrasi ini telah diterapkan.
4. Hapus komentar pada kode dalam metode Up. Ini berarti bahwa ketika migrasi ini diterapkan ke database mendatang, skema yang sudah ada di database lokal akan dibuat oleh migrasi.

Hal-hal yang perlu diperhatikan

Ada beberapa hal yang perlu Anda waspadai saat menggunakan Migrasi terhadap database yang ada.

Nama default/terhitung mungkin tidak cocok dengan skema yang ada

Migrasi menentukan secara eksplisit nama untuk kolom dan tabel saat membuat perancah migrasi. Namun, ada objek database lain yang proses migrasi menghitungkan nama default-nya saat menerapkan migrasi. Ini termasuk indeks dan batasan kunci asing. Saat menargetkan skema yang ada, nama yang dihitung ini mungkin tidak cocok dengan apa yang sebenarnya ada di database Anda.

Berikut adalah beberapa contoh kapan Anda perlu menyadari hal ini:

Jika Anda menggunakan 'Opsi Satu: Gunakan skema yang ada sebagai titik awal' dari Langkah 3:

• Jika perubahan di masa mendatang dalam model Anda mengharuskan mengubah atau menghilangkan salah satu objek database yang diberi nama berbeda, Anda harus memodifikasi migrasi perancah untuk menentukan nama yang benar. API Migrasi memiliki parameter Nama opsional yang memungkinkan Anda melakukan ini. Misalnya, skema Anda yang ada mungkin memiliki tabel Posting dengan kolom kunci asing BlogId yang memiliki indeks bernama IndexFk_BlogId. Namun, secara default, Migrasi akan mengharapkan indeks ini diberi nama IX_BlogId. Jika Anda membuat perubahan pada model Anda yang menghapus indeks ini, Anda harus memodifikasi panggilan DropIndex yang dibuat secara otomatis untuk menentukan nama IndexFk_BlogId.

Jika Anda menggunakan 'Opsi Dua: Gunakan database kosong sebagai titik awal' dari Langkah 3:

• Mencoba menjalankan metode Down dari migrasi awal (yaitu, mengembalikan ke database kosong) terhadap database lokal Anda mungkin gagal karena Migrasi akan mencoba menghilangkan indeks dan batasan kunci asing menggunakan nama yang salah. Ini hanya akan memengaruhi database lokal Anda karena database lain akan dibuat dari awal menggunakan metode Up dari migrasi awal. Jika Anda ingin menurunkan tingkat database lokal yang ada ke status kosong, paling mudah untuk melakukan ini secara manual, baik dengan menghilangkan database atau menjatuhkan semua tabel. Setelah penurunan awal ini, semua objek database akan dibuat ulang dengan nama default, sehingga masalah ini tidak akan muncul lagi.
• Jika perubahan di masa mendatang dalam model Anda mengharuskan mengubah atau menghilangkan salah satu objek database yang diberi nama berbeda, ini tidak akan berfungsi terhadap database lokal Anda yang ada - karena nama tidak akan cocok dengan default. Namun, ini akan bekerja terhadap database yang dibuat 'dari awal' karena mereka akan menggunakan nama default yang dipilih oleh Migrations. Anda dapat membuat perubahan ini secara manual pada database lokal yang sudah ada, atau mempertimbangkan agar Migrasi membuat ulang database Anda dari awal - seperti yang terjadi pada komputer lain.
• Database yang dibuat menggunakan metode Up dari migrasi awal Anda mungkin sedikit berbeda dari database lokal karena nama default yang dihitung untuk indeks dan batasan kunci asing akan diterapkan. Anda mungkin juga berakhir dengan indeks tambahan karena Migrasi akan membuat indeks pada kolom kunci asing secara default - ini mungkin belum terjadi di database lokal asli Anda.

Tidak semua objek database diwakili dalam model

Objek database yang bukan bagian dari model Anda tidak akan ditangani oleh Migrasi. Ini dapat mencakup tampilan, prosedur tersimpan, izin, tabel yang bukan bagian dari model Anda, indeks tambahan, dll.

Berikut adalah beberapa contoh kapan Anda perlu menyadari hal ini:

• Terlepas dari opsi yang Anda pilih di 'Langkah 3', jika perubahan di masa mendatang dalam model Anda memerlukan perubahan atau penghapusan objek tambahan ini Migrasi tidak akan tahu untuk membuat perubahan ini. Misalnya, jika Anda menghapus kolom yang memiliki indeks tambahan di dalamnya, migrasi tidak akan tahu untuk menghapus indeks. Anda harus menambahkan ini secara manual ke Migrasi yang di-scaffold.
• Jika Anda menggunakan 'Opsi Dua: Gunakan database kosong sebagai titik awal', objek tambahan ini tidak akan dibuat oleh metode Up migrasi awal Anda. Anda dapat memodifikasi metode Naik dan Turun untuk mengurus objek tambahan ini jika Anda mau. Untuk objek yang tidak didukung secara asli di API Migrasi – seperti tampilan – Anda dapat menggunakan metode Sql untuk menjalankan SQL mentah untuk membuat/menghilangkannya.