Aracılığıyla paylaş


Mevcut bir veritabanıyla Code First Migrations

Dekont

EF4.3 Yalnızca Devamı - Bu sayfada ele alınan özellikler, API'ler vb. Entity Framework 4.1'de sunulmuştur. Önceki bir sürümü kullanıyorsanız, bilgilerin bir kısmı veya tümü geçerli değildir.

Bu makale, Entity Framework tarafından oluşturulmamış olan mevcut bir veritabanıyla Code First Migrations'ın kullanılmasını kapsar.

Dekont

Bu makalede, temel senaryolarda Code First Migrations'ın nasıl kullanılacağını bildiğiniz varsayılır. Aksi takdirde devam etmeden önce Code First Migrations'ı okumanız gerekir.

1. Adım: Model oluşturma

İlk adımınız, mevcut veritabanınızı hedefleyen bir Code First modeli oluşturmak olacaktır. Var Olan Bir Veritabanına İlk Kod konusu, bunun nasıl yapılacağını gösteren ayrıntılı yönergeler sağlar.

Dekont

Modelinizde veritabanı şemasında değişiklik yapılmasını gerektirecek değişiklikler yapmadan önce bu konudaki diğer adımları izlemeniz önemlidir. Aşağıdaki adımlar, modelin veritabanı şemasıyla eşitlenmiş olmasını gerektirir.

2. Adım: Geçişleri Etkinleştirme

Sonraki adım, geçişleri etkinleştirmektir. Bunu yapmak için Paket Yöneticisi Konsolu'nda Geçişleri Etkinleştir komutunu çalıştırabilirsiniz.

Bu komut, çözümünüzde Migrations adlı bir klasör oluşturur ve içine Configuration adlı tek bir sınıf koyar. Yapılandırma sınıfı, uygulamanız için geçişleri yapılandırdığınız yerdir. Bu sınıf hakkında daha fazla bilgi için İlk Kod Geçişleri konusunu bulabilirsiniz.

3. Adım: İlk geçiş ekleme

Geçişler oluşturulduktan ve yerel veritabanına uygulandıktan sonra bu değişiklikleri diğer veritabanlarına da uygulamak isteyebilirsiniz. Örneğin, yerel veritabanınız bir test veritabanı olabilir ve sonuçta değişiklikleri bir üretim veritabanına ve/veya diğer geliştirici test veritabanlarına da uygulamak isteyebilirsiniz. Bu adım için iki seçenek vardır ve seçmeniz gereken seçenek, diğer veritabanlarının şemasının boş olup olmadığına veya şu anda yerel veritabanının şemasıyla eşleşip eşleşmediğine bağlıdır.

  • Birinci Seçenek: Var olan şemayı başlangıç noktası olarak kullanın. Gelecekte geçişlerin uygulanacağı diğer veritabanları şu anda yerel veritabanınızla aynı şemaya sahip olduğunda bu yaklaşımı kullanmalısınız. Örneğin, yerel test veritabanınız şu anda üretim veritabanınızın v1 sürümüyle eşleşiyorsa ve daha sonra üretim veritabanınızı v2'ye güncelleştirmek için bu geçişleri uygulayacaksanız bunu kullanabilirsiniz.
  • İkinci Seçenek: Başlangıç noktası olarak boş veritabanı kullanın. Gelecekte geçişlerin uygulanacağı diğer veritabanları boş olduğunda (veya henüz mevcut olmadığında) bu yaklaşımı kullanmalısınız. Örneğin, uygulamanızı bir test veritabanı kullanarak geliştirmeye başladıysanız ancak geçişleri kullanmadan bunu kullanabilirsiniz ve daha sonra sıfırdan bir üretim veritabanı oluşturmak isteyebilirsiniz.

Birinci Seçenek: Var olan şemayı başlangıç noktası olarak kullanma

Code First Migrations, modelde yapılan değişiklikleri algılamak için en son geçişte depolanan modelin anlık görüntüsünü kullanır (Bu konuda ayrıntılı bilgileri Takım Ortamlarındaki İlk Kod Geçişleri bölümünde bulabilirsiniz). Veritabanlarının geçerli modelin şemasına zaten sahip olduğunu varsayacağımızdan, geçerli modeli anlık görüntü olarak içeren boş (işlemsiz) bir geçiş oluşturacağız.

  1. Paket Yöneticisi Konsolunda Add-Migration InitialCreate –IgnoreChanges komutunu çalıştırın. Bu, anlık görüntü olarak geçerli modelle boş bir geçiş oluşturur.
  2. Paket Yöneticisi Konsolu'nda Update-Database komutunu çalıştırın. Bu, veritabanına InitialCreate geçişini uygular. Gerçek geçiş herhangi bir değişiklik içermediğinden, __MigrationsHistory tablosuna bu geçişin zaten uygulandığını belirten bir satır ekler.

İkinci Seçenek: Boş veritabanını başlangıç noktası olarak kullanma

Bu senaryoda, yerel veritabanımızda zaten mevcut olan tablolar da dahil olmak üzere, Geçişler'in veritabanının tamamını sıfırdan oluşturabilmesi gerekir. Mevcut şemayı oluşturmak için mantık içeren bir InitialCreate geçişi oluşturacağız. Ardından mevcut veritabanımızın bu geçiş uygulanmış gibi görünmesini sağlayacağız.

  1. Paket Yöneticisi Konsolunda Add-Migration InitialCreate komutunu çalıştırın. Bu, mevcut şemayı oluşturmak için bir geçiş oluşturur.
  2. Yeni oluşturulan geçişin Up yöntemindeki tüm kodlara açıklama ekleyin. Bu, zaten var olan tüm tabloları yeniden oluşturmaya çalışmadan yerel veritabanına geçişi 'uygulamamıza' olanak tanır.
  3. Paket Yöneticisi Konsolu'nda Update-Database komutunu çalıştırın. Bu, veritabanına InitialCreate geçişini uygular. Gerçek geçiş herhangi bir değişiklik içermediğinden (geçici olarak açıklama eklediğimiz için), __MigrationsHistory tablosuna bu geçişin zaten uygulandığını belirten bir satır ekler.
  4. Up yöntemindeki kodun açıklamasını kaldırın. Bu, bu geçiş gelecekteki veritabanlarına uygulandığında, yerel veritabanında zaten var olan şemanın geçişler tarafından oluşturulacağı anlamına gelir.

Dikkat edilmesi gerekenler

Geçişleri mevcut bir veritabanında kullanırken bilmeniz gereken birkaç şey vardır.

Varsayılan/hesaplanan adlar mevcut şemayla eşleşmeyebilir

Geçişler, geçişlerin iskelesini oluştururken sütunların ve tabloların adlarını açıkça belirtir. Ancak Migrations'ın geçişleri uygularken varsayılan bir ad hesaplayan başka veritabanı nesneleri de vardır. Buna dizinler ve yabancı anahtar kısıtlamaları dahildir. Mevcut bir şemayı hedeflerken, bu hesaplanmış adlar veritabanınızda gerçekten var olan adlarla eşleşmeyebilir.

Bunun farkında olmanız gereken bazı örnekler aşağıda verilmiştir:

3. Adım'dan 'Birinci Seçenek: Var olan şemayı başlangıç noktası olarak kullan' seçeneğini kullandıysanız:

  • Modelinizde gelecekte yapılacak değişiklikler farklı adlı veritabanı nesnelerinden birinin değiştirilmesini veya bırakılacağını gerektiriyorsa, doğru adı belirtmek için yapı iskelesi geçişini değiştirmeniz gerekir. Migrations API'lerinin bunu yapmanızı sağlayan isteğe bağlı bir Name parametresi vardır. Örneğin, mevcut şemanızda IndexFk_BlogId adlı bir dizine sahip BlogId yabancı anahtar sütununa sahip bir Post tablosu olabilir. Ancak, varsayılan olarak Migrations bu dizinin IX_BlogId olarak adlandırılması beklenebilir. Modelinizde bu dizinin bırakılmasıyla sonuçlanan bir değişiklik yaparsanız, IndexFk_BlogId adını belirtmek için iskeleli DropIndex çağrısını değiştirmeniz gerekir.

Adım 3'ten 'İkinci Seçenek: Başlangıç noktası olarak boş veritabanı kullan' seçeneğini kullandıysanız:

  • Geçişler dizinleri ve yabancı anahtar kısıtlamalarını yanlış adları kullanarak bırakmaya çalışacağından, ilk geçişin Down yöntemini (boş bir veritabanına geri dönme) yerel veritabanınıza karşı çalıştırmaya çalışmak başarısız olabilir. Diğer veritabanları ilk geçişin Up yöntemi kullanılarak sıfırdan oluşturulacağı için bu yalnızca yerel veritabanınızı etkiler. Mevcut yerel veritabanınızı boş bir duruma düşürmek istiyorsanız, veritabanını bırakarak veya tüm tabloları bırakarak bunu el ile yapmak en kolayıdır. Bu ilk sürüm düşürme işleminden sonra tüm veritabanı nesneleri varsayılan adlarla yeniden oluşturulur, bu nedenle bu sorun yeniden sunulmaz.
  • Modelinizdeki gelecekteki değişiklikler farklı adlı veritabanı nesnelerinden birinin değiştirilmesini veya bırakıldığını gerektiriyorsa, adlar varsayılan değerlerle eşleşmeyeceğinden bu, mevcut yerel veritabanınızda çalışmaz. Ancak, Geçişler tarafından seçilen varsayılan adları kullanacağı için 'sıfırdan' oluşturulan veritabanlarında çalışır. Bu değişiklikleri yerel mevcut veritabanınızda el ile yapabilir veya Diğer makinelerde olduğu gibi Geçişler'in veritabanınızı sıfırdan yeniden oluşturmalarını sağlayabilirsiniz.
  • İlk geçişinizin Up yöntemi kullanılarak oluşturulan veritabanları, dizinler ve yabancı anahtar kısıtlamaları için hesaplanan varsayılan adlar kullanılacağından yerel veritabanından biraz farklı olabilir. Geçişler varsayılan olarak yabancı anahtar sütunlarında dizinler oluşturacağı için fazladan dizinler de elde edebilirsiniz; özgün yerel veritabanınızda bu durum geçerli olmayabilir.

Modelde tüm veritabanı nesneleri temsil edilmez

Modelinizin parçası olmayan veritabanı nesneleri Geçişler tarafından işlenmez. Bu görünümler, saklı yordamlar, izinler, modelinizin parçası olmayan tablolar, ek dizinler vb. içerebilir.

Bunun farkında olmanız gereken bazı örnekler aşağıda verilmiştir:

  • '3. Adım'da seçtiğiniz seçenek ne olursa olsun, modelinizdeki gelecekteki değişiklikler bu ek nesnelerin değiştirilmesini veya bırakılacağını gerektiriyorsa Migrations bu değişiklikleri yapmayı bilemez. Örneğin, üzerinde ek dizini olan bir sütunu bırakırsanız, Migrations dizinin bırakılacağını bilmez. Bunu iskeleli Geçiş'e el ile eklemeniz gerekir.
  • 'İkinci Seçenek: Boş veritabanını başlangıç noktası olarak kullan' kullandıysanız, bu ek nesneler ilk geçişinizin Up yöntemi tarafından oluşturulmaz. İsterseniz bu ek nesnelerle ilgilenmek için Yukarı ve Aşağı yöntemlerini değiştirebilirsiniz. Geçişler API'sinde yerel olarak desteklenmeyen nesneler için (görünümler gibi) bunları oluşturmak/bırakmak için ham SQL çalıştırmak için Sql yöntemini kullanabilirsiniz.