EF Core 10'un adlandırılmış varsayılan kısıtlamaları SQL Server'a öngörülebilir isimler getiriyor — tek migration uyarısıyla

Adlandırılmış varsayılanlar EF Core 10'da geldi

EF Core 10, SQL Server için adlandırılmış varsayılan kısıtlamalar (default constraint) getiriyor. Şimdiye dek SQL Server, varsayılan kısıtlamlara DF__Jobs__Status__... gibi önceden tahmin edilmesi fiilen imkânsız, makine tarafından üretilmiş isimler atıyordu. Bu durum, bir kısıtı ismiyle referans vermesi gereken dağıtım betikleri, DBA runbook'ları ve geri alma prosedürleri için işleri zorlaştırıyordu. Bir dev.to yazısına göre yeni özellik, her varsayılana kalıcı bir isim vererek bunu çözüyor.

Bunu kullanmanın iki yolu var. Tek tek property'lere HasDefaultValue veya HasDefaultValueSql çağrılarında doğrudan bir isim geçebilir ya da OnModelCreating içinde UseNamedDefaultConstraints() çağırarak model genelinde geçerli bir convention etkinleştirebilirsiniz. Convention açıkken, bir Jobs entity'sinde tanımlanan varsayılanlar DF_Jobs_Status, DF_Jobs_CreatedUtc ve DF_Jobs_RetryCount gibi isimler üretir — deterministik ve okunabilir.

Tuzak: bir sonraki migration tüm varsayılanları yeniden yazar

Convention, mevcut bir şemaya uygulandığında zararsız bir metadata ayarı değildir. dev.to gönderisinde atıf yapılan Microsoft'un EF Core 10 sürüm notları, bir sonraki migration'ın modeldeki tüm varsayılan kısıtların isimlerini değiştirdiği konusunda uyarıyor. Yalnızca migration'ların derlenip derlenmediğini kontrol eden bir CI build'i, değişikliğin gerçekte ne kadar geniş olduğunu göstermez.

Teknik olarak, üretilen migration etkilenen her sütun için AlterColumn operasyonlarından oluşur. CLR tipi ve varsayılan değer aynı kalır; değişen şey, yeni ismi taşıyan Relational:DefaultConstraintName annotation'ının eklenmesidir. Üretilen SQL'de EF, opak eski ismi bulmak için sys.default_constraints'i sorgular, onu düşürür, sütunu değiştirir ve kısıtı öngörülebilir isimle yeniden ekler; bu diziyi her varsayılan için bir kez yineler.

Veritabanı olmadan SQL'i önizlemek

dev.to yazarı, iki commit edilmiş migration etrafında çalıştırılabilir bir örnek hazırlamış: üç isimsiz varsayılanlı eski modeli temsil eden InitialSchema ve convention etkinleştirildikten sonra scaffold edilen NameDefaultConstraints. Betiği üretmek canlı bir bağlantı gerektirmez, çünkü SQL Server provider'ı commit edilmiş operasyonları dotnet-ef migrations script ile yerel olarak çevirebilir.

Önizleme, gerçekte çalışacak olanı gösterir: kısıt aramaları, düşürmeler, sütun değişiklikleri ve yeniden oluşturulan varsayılanlar. Betik hiçbir tablo veya sütun düşürmez, ancak yine de kilitleme ve dağıtım süresi açısından incelenmeye değer bir şema işidir.

Önizlemeyi deterministik bir kapıya dönüştürmek

Tek seferlik bir okumanın ötesinde, yazı önizlemeyi çalıştırılabilir kontrollere dönüştürüyor. Doğrulayıcı, placeholder bağlantısını hiç açmadan EF'nin migration servislerini çözer, migration'ın up operasyonlarını inceler ve SQL'i sıfırdan oluşturulan context'lerden iki kez yeniden üretir. Tam olarak üç AlterColumn operasyonu olduğunu, betikte üç DROP CONSTRAINT ifadesi bulunduğunu, beklenen üç DF_ isminin göründüğünü, sys.default_constraints'e üç kez başvurulduğunu, DROP TABLE ve DROP COLUMN'ın bulunmadığını ve placeholder bağlantısının kapalı kaldığını assert eder. Doğrulayıcıyı beş kez çalıştırmak birbirinin aynısı çıktı verdi.

Yazar, tüm SQL dosyasının snapshot'ını almaktansa bu semantik assertion'ları tercih ediyor, çünkü provider yamaları anlamı değiştirmeden boşlukları, batch ayırıcılarını veya yerel değişken isimlerini değiştirebilir. İleride biri dördüncü bir varsayılan eklerse test bilinçli olarak başarısız olur ve sessizce daha geniş bir migration'ı kabullenmek yerine bir kapsam incelemesini zorunlu kılar. Bu yaklaşım, migration'ın ne yapmayı amaçladığını SQL Server, kimlik bilgisi veya tek kullanımlık bir veritabanı gerektirmeden yanıtlar; dolayısıyla bir integration test değil, bir contract test olarak işlev görür. Yazar, üretim öncesi migration'ı temsili bir veritabanına uygulamayı yine de öneriyor, çünkü çevrimdışı bir betik kilit süresini, iş yükü çekişmesini veya provider izinlerini tahmin edemez — bu da üretilen migration'ların incelenip özelleştirilmesi gerektiğine dair Microsoft'un kendi yönergeleriyle uyumlu.

Global convention'dan ne zaman kaçınılmalı

Yeni bir şema için global convention kullanışlı bir seçimdir, çünkü isimler ilk migration'dan itibaren mevcuttur. Büyük veya yoğun bir veritabanı için yazı, kademeli bir geçiş öneriyor: API SQL Server'a özeldir ve property düzeyindeki overload'lar önce seçili varsayılanları isimlendirmenize izin verir; bu da alakasız bir model düzenlemesinin geniş bir migration'a dönüşmesini engeller. Yazar ayrıca operasyon sayısını performans tahmini olarak okumamak konusunda uyarıyor — bir demoda yapılan üç hızlı değişiklik, yoğun üretilen tablolardaki yüzlerce varsayılan hakkında hiçbir şey söylemez.

Neden önemli

Küçük bir yapılandırma bayrağının sessizce bir migration'ı yeniden şekillendirmesi klasik bir yükseltme tehlikesidir. Adlandırılmış varsayılan kısıtlamalar SQL Server işletilebilirliğini gerçekten iyileştirir; ancak isimleri düzene sokan tek satırlık bu convention, bir dahaki sefere migration üretildiğinde modeldeki tüm varsayılanlara da dokunur. EF Core 10'a yükselen ekipler migration betiğini önizlemeli — yazının gösterdiği gibi bu, canlı bir veritabanı gerektirmez — ve beklenen kapsamı CI'da assert etmeyi düşünümlü ki değişikliğin büyüklüğü dağıtım sırasında değil, öncesinde incelenebilsin.