Bagikan melalui

Migrasi Pertama Kode dengan database yang sudah ada

  • Artikel

Catatan

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.

Catatan

Artikel ini mengasumsikan Anda tahu cara menggunakan Migrasi Pertama Kode dalam skenario dasar. Jika tidak, Maka Anda harus membaca Migrasi Pertama Kode 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.

Catatan

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 (tanpa operasi) 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 rekam jepret.
  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. Batalkan komentar kode dalam metode Naik. Ini berarti bahwa ketika migrasi ini diterapkan ke database mendatang, skema yang sudah ada di database lokal akan dibuat oleh migrasi.

Hal-hal yang harus 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 secara eksplisit menentukan nama untuk kolom dan tabel saat perancah migrasi. Namun, ada objek database lain yang dihitung Migrasi nama default saat menerapkan migrasi. Ini termasuk indeks dan batasan kunci asing. Saat menargetkan skema yang ada, nama terhitung 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 menghasilkan penurunan indeks ini, Anda harus memodifikasi panggilan DropIndex yang dibuat perancah 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 Migrasi. 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 terhitung untuk indeks dan batasan kunci asing akan digunakan. 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 menjatuhkan kolom yang memiliki indeks tambahan di dalamnya, Migrasi tidak akan tahu untuk menghilangkan 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 Atas 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.