Aracılığıyla paylaş

EF Core 9'da (EF9) hataya neden olan değişiklikler

  • Makale

Bu sayfada, EF Core 8'den EF Core 9'a güncelleştirilen mevcut uygulamaların bozulmasına neden olabilecek API ve davranış değişiklikleri belgelenmiştir. EF Core'un önceki bir sürümünden güncelleştirme yapıyorsanız, önceki hataya neden olan değişiklikleri gözden geçirmeyi unutmayın:

Hedef Çerçeve

EF Core 9, .NET 8'i hedefler. Bu, .NET 8'i hedefleyen mevcut uygulamaların bunu yapmaya devam edebilmesi anlamına gelir. Eski .NET, .NET Core ve .NET Framework sürümlerini hedefleyen uygulamaların EF Core 9 kullanmak için .NET 8 veya .NET 9'un hedeflenmesi gerekir.

Özet

Not

Azure Cosmos DB kullanıyorsanız azure cosmos DB hataya neden olan değişikliklerle ilgili aşağıdaki ayrı bölüme bakın.

Hataya neden olan değişiklik Etki
Geçişler uygulanırken Özel Durum oluşturulur bekleyen model değişiklikleri olduğunda. Yüksek
Açık bir işlemde geçişler uygulanırken özel durum fırlatılır Yüksek
EF araçları kullanılırkenMicrosoft.EntityFrameworkCore.Design bulunamadı Orta
EF.Functions.Unhex() şimdi döndürüyor byte[]? Düşük
SqlFunctionExpression'ın null atanabilirlik bağımsız değişkenlerinin arity değeri doğrulandı Düşük
ToString() yöntemi artık örnekler için null boş dize döndürüyor Düşük
Paylaşılan çerçeve bağımlılıkları 9.0.x sürümüne güncelleştirildi Düşük

Yüksek etkili değişiklikler

Model değişiklikleri bekliyorsa geçişler uygulanırken istisna fırlatılır.

İzleme Sorunu #33732

Eski davranış

Modelde son geçişle karşılaştırıldığında bekleyen değişiklikler varsa, Migrate çağrıldığında geri kalan geçişlerle uygulanmaz.

Yeni davranış

EF Core 9.0'dan başlayarak, modelde son geçişle karşılaştırıldığında bekleyen değişiklikler varsa, dotnet ef database update, Migrate veya MigrateAsync çağrıldığında bir istisna oluşur.

'DbContext' bağlamı modelinde bekleyen değişiklikler var. Veritabanını güncelleştirmeden önce yeni bir geçiş ekleyin. Bu özel durum, 'RelationalEventId.PendingModelChangesWarning' olay kimliği 'DbContext.OnConfiguring' veya 'AddDbContext' içindeki 'ConfigureWarnings' yöntemine geçirilerek gizlenebilir veya günlüğe kaydedilebilir.

Neden?

Model değişiklikleri yaptıktan sonra yeni bir geçiş eklemeyi unutmak, bazı durumlarda tanılanması zor olabilecek yaygın bir hatadır. Yeni özel durum, geçişler uygulandıktan sonra uygulamanın modelinin veritabanıyla eşleşmesini sağlar.

Risk Azaltıcı Etkenler

Bu istisnanın atılabileceği birkaç yaygın durum vardır:

  • Hiç geçiş yok. Bu durum, veritabanı başka yollarla güncelleştirildiğinde sık karşılaşılan bir durumdur.
    • Azaltma: Veritabanı şemasını yönetmek için geçişleri kullanmayı planlamıyorsanız Migrate veya MigrateAsync çağrısını kaldırın, aksi takdirde bir geçiş ekleyin.
  • En az bir geçiş mevcut, ancak modelin anlık görüntüsü eksik. Bu, el ile oluşturulan geçişlerde yaygındır.
    • Azaltma: EF araçlarını kullanarak yeni bir geçiş ekleyin; bu işlem model anlık görüntüsünü güncelleştirir.
  • Model geliştirici tarafından değiştirilmedi, ancak deterministik olmayan bir şekilde oluşturulduğundan EF tarafından değiştirilmiş olarak algılanıyor. new DateTime()için sağlanan nesnelerde DateTime.Now, DateTime.UtcNow, Guid.NewGuid()veya HasData() kullanıldığında bu yaygın bir durumdur.
    • Azaltma: Yeni bir geçiş ekleyin, nedenini bulmak için içeriğini inceleyin ve dinamik verileri modelde statik, sabit kodlanmış bir değerle değiştirin. Model düzeltildikten sonra geçiş yeniden oluşturulmalıdır. Dinamik verilerin tohumlama için kullanılması gerekiyorsa, yerine HasData() kullanmayı göz önünde bulundurun.
  • Son geçiş, geçişleri uygulamak için kullanılan sağlayıcıdan farklı bir sağlayıcı için oluşturuldu.
    • Azaltma: Bu desteklenmeyen bir senaryodur. Uyarı aşağıdaki kod parçacığı kullanılarak gizlenebilir, ancak bu senaryo büyük olasılıkla gelecekteki bir EF Core sürümünde çalışmayı durduracaktır. Önerilen çözüm, her sağlayıcı için ayrı bir geçiş kümesi oluşturmak üzere .
  • Geçişler, bazı EF hizmetlerinin yerine başkaları geçirilerek dinamik olarak oluşturulur ya da seçilir.

    • Azaltma: Uyarı bu durumda hatalı bir pozitiftir ve gizlenmelidir:

      options.ConfigureWarnings(w => w.Ignore(RelationalEventId.PendingModelChangesWarning))

Senaryonuz yukarıdaki durumlardan hiçbirine uymuyorsa ve yeni bir geçiş eklemek her seferinde aynı geçişi ya da boş bir geçiş oluşturuyorsa ve yine de bir istisna oluşuyorsa, küçük bir yeniden oluşturma projesi hazırlayın ve bunu EF ekibiyle yeni bir sorun açarak paylaşın.

Açık bir işlemde geçişler uygulanırken istisna fırlatıldı

İzleme Sorunu #17578

Eski davranış

Geçişleri dayanıklı bir şekilde uygulamak için yaygın olarak aşağıdaki desen kullanılmıştır:

await dbContext.Database.CreateExecutionStrategy().ExecuteAsync(async () =>
{
    await using var transaction = await dbContext.Database.BeginTransactionAsync(cancellationToken);
    await dbContext.Database.MigrateAsync(cancellationToken);
    await transaction.CommitAsync(cancellationToken);
});

Yeni davranış

EF Core 9.0'dan itibaren Migrate ve MigrateAsync çağrıları bir işlem başlatır ve komutları ExecutionStrategy kullanarak yürütür. Uygulamanız yukarıdaki deseni kullanıyorsa, bir istisna fırlatılır.

'Microsoft.EntityFrameworkCore.Migrations.MigrationsUserTransactionWarning' uyarısı için bir hata oluşturuldu: Geçişler uygulanmadan önce bir işlem başlatıldı. Bu, veritabanı kilidinin alınmasını engeller ve bu nedenle veritabanı eşzamanlı geçiş uygulamalarından korunmaz. İşlemler ve yürütme stratejisi gerektiğinde ZATEN EF tarafından yönetilir. Harici işlemi kaldırın. Bu özel durum, 'RelationalEventId.MigrationsUserTransactionWarning' olay kimliğini 'DbContext.OnConfiguring' veya 'AddDbContext' içindeki 'ConfigureWarnings' yöntemine geçirerek bastırılabilir veya günlüğe kaydedilebilir.

Neden?

Açık bir işlem kullanmak veritabanı kilidinin alınmasını engeller ve bu nedenle veritabanı eşzamanlı geçiş uygulamalarından korunmaz, ayrıca EF'yi işlemleri dahili olarak nasıl yönetebileceği konusunda sınırlar.

Risk Azaltıcı Etkenler

İşlemin içinde yalnızca bir veritabanı çağrısı varsa dış işlemi kaldırın ve ExecutionStrategy:

await dbContext.Database.MigrateAsync(cancellationToken);

Aksi takdirde, senaryonuz açık bir işlem gerektiriyorsa ve eşzamanlı geçiş uygulamasını önlemek için başka bir mekanizmanız varsa uyarıyı yoksayın:

options.ConfigureWarnings(w => w.Ignore(RelationalEventId.MigrationsUserTransactionWarning))

Orta düzeyde etki eden değişiklikler

EF araçları kullanılırken Microsoft.EntityFrameworkCore.Design bulunamadı

Takip Sorunu #35265

Eski davranış

Önceden EF araçlarına aşağıdaki şekilde başvurulmak Microsoft.EntityFrameworkCore.Design gerekiyordu.

    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="*.0.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>

Yeni davranış

.NET SDK 9.0.200'den başlayarak EF aracı çağrıldığında bir özel durum oluşur:

'Microsoft.EntityFrameworkCore.Design, Culture=neutral, PublicKeyToken=null' dosyası veya derlemesi yüklenemedi. Sistem belirtilen dosyayı bulamıyor.

Neden?

EF araçları, özel varlıkların oluşturulan .deps.json dosyasına eklenmesine neden olan belgelenmemiş bir .NET SDK davranışına güveniyordu. Bu, sdk#45259içinde düzeltildi. Ne yazık ki, bunu hesaba katacak EF değişikliği EF 9.0.x hizmet standardını karşılamadığından, bu durum EF 10'da düzeltilecektir.

Risk Azaltıcı Etkenler

EF 10 yayımlanmadan önce geçici bir çözüm olarak, Design derleme başvurusunu yayımlanabilir olarak belirtebilirsiniz:

    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="9.0.1">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <Publish>true</Publish>
    </PackageReference>

Bu işlem, oluşturulan .deps.json dosyasına dahil edilmesini sağlar, ancak bunun yan etkisi, Microsoft.EntityFrameworkCore.Design.dll dosyasını çıkış ve yayın klasörlerine kopyalamaktır.

Düşük etkili değişiklikler

EF.Functions.Unhex() şimdi döndürüyor byte[]?

İzleme Sorunu #33864

Eski davranış

İşleve EF.Functions.Unhex() daha önce döndürülmesi byte[]için ek açıklama eklendi.

Yeni davranış

EF Core 9.0'dan başlayarak Unhex() artık döndürülmesi byte[]?için ek açıklama eklenmiştir.

Neden?

Unhex() geçersiz girişler için NULL döndüren SQLite unhex işlevine çevrilir. Sonuç olarak, Unhex() ek açıklamayı ihlal eden bu durumlar için döndürülür null .

Risk Azaltıcı Etkenler

öğesine geçirilen metin içeriğinin geçerli, onaltılık bir dizeyi Unhex() temsil edeceğinden eminseniz, çağırmanın hiçbir zaman null döndürmeyeceğini belirten bir onay olarak null-forgiving işlecini eklemeniz yeterlidir:

var binaryData = await context.Blogs.Select(b => EF.Functions.Unhex(b.HexString)!).ToListAsync();

Aksi takdirde, Unhex() dönüş değerinde null için çalışma zamanı denetimleri ekleyin.

SqlFunctionExpression'ın null atanabilirlik bağımsız değişkenlerinin arity değeri doğrulandı

İzleme Sorunu #33852

Eski davranış

Daha önce farklı sayıda bağımsız değişken ve null atanabilirlik yayma bağımsız değişkenleriyle bir SqlFunctionExpression oluşturmak mümkündü.

Yeni davranış

EF Core 9.0'dan başlayarak, bağımsız değişken sayısı ve null atanabilirlik yayma bağımsız değişkenleri eşleşmiyorsa EF şimdi atar.

Neden?

Eşleşen sayıda bağımsız değişken ve null atanabilirlik yayma bağımsız değişkeninin olmaması beklenmeyen davranışa yol açabilir.

Risk Azaltıcı Etkenler

öğesinin ile argumentsPropagateNullability aynı sayıda öğeye argumentssahip olduğundan emin olun. Şüpheli olduğunda, null atanabilirlik bağımsız değişkeni için kullanın false .

ToString() yöntemi artık örnekler için null boş dize döndürüyor

İzleme Sorunu #33941

Eski davranış

Daha önce EF, bağımsız değişken değeri olduğunda yöntemi için ToString() tutarsız sonuçlar döndürdü null. ÖrneğinToString(), değeri döndürülen bool?özelliğinde nullnull, ancak değeri bool? döndürülen nullözellik True olmayan ifadeler için. Davranış diğer veri türleri için de tutarsızdı; örneğin ToString()null değer sabit listesi boş dize döndürdü.

Yeni davranış

EF Core 9.0'dan başlayarak, ToString() bağımsız değişken değeri olduğunda nullyöntemi artık her durumda tutarlı olarak boş dize döndürür.

Neden?

Eski davranış, farklı veri türleri ve durumlarda tutarsızdı ve C# davranışıyla uyumlu değildi.

Risk Azaltıcı Etkenler

Eski davranışa dönmek için sorguyu uygun şekilde yeniden yazın:

var newBehavior = context.Entity.Select(x => x.NullableBool.ToString());
var oldBehavior = context.Entity.Select(x => x.NullableBool == null ? null : x.NullableBool.ToString());

Paylaşılan çerçeve bağımlılıkları 9.0.x sürümüne güncelleştirildi

Eski davranış

SDK kullanan Microsoft.NET.Sdk.Web ve net8.0'ı hedefleyen uygulamalar paylaşılan çerçeveden , System.Text.Json, Microsoft.Extensions.Caching.MemoryMicrosoft.Extensions.Configuration.Abstractions ve Microsoft.Extensions.Logging gibi Microsoft.Extensions.DependencyModelpaketleri çözümlediğinden, bu derlemeler normalde uygulamayla dağıtılmaz.

Yeni davranış

EF Core 9.0 hala net8.0'ı desteklese de artık , , System.Text.JsonMicrosoft.Extensions.Caching.MemoryMicrosoft.Extensions.Configuration.Abstractionsve Microsoft.Extensions.Loggingsürümlerinin 9.0.x sürümlerine Microsoft.Extensions.DependencyModelbaşvurur. Net8.0'ı hedefleyen uygulamalar, bu derlemelerin dağıtılmasını önlemek için paylaşılan çerçeveden yararlanamaz.

Neden?

Eşleşen bağımlılık sürümleri en son güvenlik düzeltmelerini içerir ve bunların kullanılması EF Core için hizmet modelini basitleştirir.

Risk Azaltıcı Etkenler

Önceki davranışı elde etmek için uygulamanızı net9.0 hedefine değiştirin.

Azure Cosmos DB'de hataya neden olan değişiklikler

Azure Cosmos DB sağlayıcısını 9.0'da daha iyi hale getirmek için kapsamlı çalışmalar gerçekleştirilmiştir. Değişiklikler bir dizi yüksek etkili hataya neden olan değişiklik içerir; Mevcut bir uygulamayı yükseltiyorsanız lütfen aşağıdakileri dikkatle okuyun.

Hataya neden olan değişiklik Etki
Discriminator özelliği artık yerine adlandırılmıştır $typeDiscriminator Yüksek
id özelliği artık varsayılan olarak ayrıştırıcıyı içermiyor Yüksek
JSON id özelliği anahtarına eşlenir Yüksek
Azure Cosmos DB sağlayıcısı aracılığıyla G/Ç eşitleme artık desteklenmiyor Orta
SQL sorgularının artık JSON değerlerini doğrudan yansıtması gerekir Orta
Tanımlanmamış sonuçlar artık sorgu sonuçlarından otomatik olarak filtreleniyor Orta
Yanlış çevrilen sorgular artık çevriliyor Orta
HasIndex şimdi yoksayılmak yerine atar Düşük
IncludeRootDiscriminatorInJsonId9.0.0-rc.2'nin ardından olarak yeniden adlandırıldı HasRootDiscriminatorInJsonId Düşük

Yüksek etkili değişiklikler

Discriminator özelliği artık yerine adlandırılmıştır $typeDiscriminator

İzleme Sorunu #34269

Eski davranış

EF, belgenin temsil ettiği varlık türünü tanımlamak için JSON belgelerine otomatik olarak bir ayrıştırıcı özelliği ekler. EF'in önceki sürümlerinde, bu JSON özelliği varsayılan olarak adlandırılmıştır Discriminator .

Yeni davranış

EF Core 9.0'dan başlayarak ayırıcı özelliği artık varsayılan olarak çağrılır $type . Azure Cosmos DB'de EF'nin önceki sürümlerinden belgeleriniz varsa bunlar eski Discriminator adlandırmayı kullanır ve EF 9.0'a yükselttikten sonra bu belgelere yönelik sorgular başarısız olur.

Neden?

Yeni ortaya çıkan bir $type JSON uygulaması, belgenin türünün tanımlanması gereken senaryolarda bir özellik kullanır. Mesela. NET'in System.Text.Json'u, varsayılan ayrımcı özellik adı ($type) olarak kullanarak polimorfizmi de destekler. Ekosistemin geri kalanıyla uyumlu hale getirmek ve dış araçlarla birlikte çalışabilirliği kolaylaştırmak için varsayılan değer değiştirildi.

Risk Azaltıcı Etkenler

En kolay azaltma, ayrıştırıcı özelliğinin adını aşağıdaki gibi olacak şekilde yapılandırmaktır Discriminator:

modelBuilder.Entity<Session>().HasDiscriminator<string>("Discriminator");

Bunu tüm üst düzey varlık türleriniz için yapmak EF'in önceki gibi davranmasını sağlar.

Bu noktada, isterseniz tüm belgelerinizi yeni $type adlandırmayı kullanacak şekilde güncelleştirebilirsiniz.

id özelliği artık varsayılan olarak yalnızca EF anahtarı özelliğini içerir

İzleme Sorunu #34179

Eski davranış

Daha önce EF, varlık türünüzün ayırıcı değerini belgenin id özelliğine eklemişti. Örneğin, 8 içeren bir özelliğe sahip bir BlogId varlık türü kaydettiyseniz, JSON id özelliği içerir Blog|8.

Yeni davranış

EF Core 9.0'dan başlayarak JSON id özelliği artık ayırıcı değerini içermez ve yalnızca anahtar özelliğinizin değerini içerir. Yukarıdaki örnekte JSON id özelliği basitçe olacaktır 8. Azure Cosmos DB'de EF'nin önceki sürümlerinden belgeleriniz varsa, bunlar JSON id özelliğinde ayrıştırıcı değerine sahiptir ve EF 9.0'a yükselttikten sonra bu belgelere yönelik sorgular başarısız olur.

Neden?

JSON id özelliğinin benzersiz olması gerektiğinden, ayrıştırıcı daha önce aynı anahtar değerine sahip farklı varlıkların var olması için eklenmiştir. Örneğin, bu, aynı kapsayıcı ve Blog bölüm içinde 8 değerini içeren bir Post özelliğe sahip hem a hem de Id değerine sahip olmasına izin verir. Bu, her varlık türünün kendi tablosuna eşlendiği ve dolayısıyla kendi anahtar alanına sahip olduğu ilişkisel veritabanı veri modelleme desenleriyle daha iyi hizalandı.

EF 9.0 genellikle eşlemeyi ilişkisel veritabanlarından gelen kullanıcıların beklentilerine karşılık gelmek yerine yaygın Azure Cosmos DB NoSQL uygulamaları ve beklentileriyle daha uyumlu olacak şekilde değiştirdi. Ayrıca, özelliğinde ayrımcı değeri olması, dış araçların ve sistemlerin id EF tarafından oluşturulan JSON belgeleriyle etkileşim kurmasını zorlaştırdı; bu tür dış sistemler varsayılan olarak .NET türlerinden türetilen EF ayırıcı değerlerinin genel olarak farkında değildir.

Risk Azaltıcı Etkenler

En kolay azaltma, EF'yi daha önce olduğu gibi JSON id özelliğine ayırıcıyı dahil etmek üzere yapılandırmaktır. Bu amaçla yeni bir yapılandırma seçeneği kullanıma sunulmuştur:

modelBuilder.Entity<Session>().HasDiscriminatorInJsonId();

Bunu tüm üst düzey varlık türleriniz için yapmak EF'in önceki gibi davranmasını sağlar.

Bu noktada, isterseniz tüm belgelerinizi güncelleştirerek JSON id özelliğini yeniden yazabilirsiniz. Bunun yalnızca farklı türlerdeki varlıklar aynı kapsayıcı içinde aynı kimlik değerini paylaşmazsa mümkün olduğunu unutmayın.

JSON id özelliği anahtara eşlenir

İzleme Sorunu #34179

Eski davranış

Daha önce EF, özelliklerden biri açıkça id eşlenmediği sürece JSON id özelliğine eşlenen bir gölge özellik oluşturmuştu.

Yeni davranış

EF Core 9'dan başlayarak anahtar özelliği mümkünse kurala göre JSON id özelliğine eşlenir. Bu, anahtar özelliğinin artık belgede aynı değere sahip farklı bir adla kalıcı hale getirilmeyeceğini, bu nedenle EF kodu olmayanların belgeleri kullanması ve bu özelliğin mevcut olmasına bağlı olarak artık düzgün çalışmayacağı anlamına gelir.

Neden?

EF 9.0 genellikle eşlemeyi yaygın Azure Cosmos DB NoSQL uygulamaları ve beklentileriyle daha uyumlu olacak şekilde değiştirdi. Anahtar değerinin belgede iki kez depolanması yaygın değildir.

Risk Azaltıcı Etkenler

EF Core 8 davranışını korumak istiyorsanız en kolay azaltma, bu amaçla kullanıma sunulan yeni bir yapılandırma seçeneği kullanmaktır:

modelBuilder.Entity<Session>().HasShadowId();

Bunu tüm üst düzey varlık türleriniz için yapmak EF'in önceki gibi davranmasını sağlar. Veya bunu tek bir çağrıyla modeldeki tüm varlık türlerine uygulayabilirsiniz:

modelBuilder.HasShadowIds();

Orta düzeyde etki eden değişiklikler

Azure Cosmos DB sağlayıcısı aracılığıyla G/Ç eşitleme artık desteklenmiyor

İzleme Sorunu #32563

Eski davranış

Daha önce veya ToList gibi SaveChanges zaman uyumlu yöntemleri çağırmak, Azure Cosmos DB SDK'sına yönelik zaman uyumsuz çağrıları yürütürken EF Core'un kullanarak .GetAwaiter().GetResult() zaman uyumlu olarak engellenmesine neden olacaktı. Bu kilitlenmeye neden olabilir.

Yeni davranış

EF Core 9.0'dan başlayarak EF artık zaman uyumlu G/Ç kullanmaya çalışırken varsayılan olarak atılıyor. Özel durum iletisi şudur: "Azure Cosmos DB zaman uyumlu G/Ç'yi desteklemiyor. Azure Cosmos DB'ye erişmek için Entity Framework Core kullanırken yalnızca zaman uyumsuz yöntemleri kullandığınızdan ve doğru şekilde beklediğinizden emin olun. Daha fazla bilgi için bkz https://aka.ms/ef-cosmos-nosync .

Neden?

Zaman uyumsuz yöntemlerde zaman uyumlu engelleme kilitlenmeye neden olabilir ve Azure Cosmos DB SDK'sı yalnızca zaman uyumsuz yöntemleri destekler.

Risk Azaltıcı Etkenler

EF Core 9.0'da hata şu şekilde gizlenebilir:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.ConfigureWarnings(w => w.Ignore(CosmosEventId.SyncNotSupported));
}

Bununla birlikte, Azure Cosmos DB SDK'sı tarafından desteklenmediğinden uygulamaların Azure Cosmos DB ile eşitleme API'lerini kullanmayı durdurması gerekir. Özel durumu gizleme özelliği, EF Core'un gelecekteki bir sürümünde kaldırılacak ve bundan sonra tek seçenek zaman uyumsuz API'leri kullanmak olacaktır.

SQL sorgularının artık JSON değerlerini doğrudan yansıtması gerekir

İzleme Sorunu #25527

Eski davranış

Daha önce EF tarafından oluşturulan sorgular şunlar gibi:

SELECT c["City"] FROM root c

Bu tür sorgular Azure Cosmos DB'nin her sonucu aşağıdaki gibi bir JSON nesnesine sarmalamasına neden olur:

[
    {
        "City": "Berlin"
    },
    {
        "City": "México D.F."
    }
]
Yeni davranış

EF Core 9.0'dan başlayarak EF artık değiştiriciyi VALUE sorgulara şu şekilde ekler:

SELECT VALUE c["City"] FROM root c

Bu tür sorgular Azure Cosmos DB'nin sarmalanmadan değerleri doğrudan döndürmesine neden olur:

[
    "Berlin",
    "México D.F."
]

Uygulamanız SQL sorgularını kullanıyorsa bu tür sorgular, değiştiriciyi içermediğinden VALUE EF 9.0'a yükselttikten sonra büyük olasılıkla bozulur.

Neden?

Her sonucun ek bir JSON nesnesine sarmalanması bazı senaryolarda performans düşüşlerine neden olabilir, JSON sonuç yükünü şişirebilir ve Azure Cosmos DB ile çalışmanın doğal yolu değildir.

Risk Azaltıcı Etkenler

Azaltmak için, değiştiriciyi VALUE yukarıda gösterildiği gibi SQL sorgularınızın projeksiyonlarına eklemeniz yeterlidir.

Tanımlanmamış sonuçlar artık sorgu sonuçlarından otomatik olarak filtreleniyor

İzleme Sorunu #25527

Eski davranış

Daha önce EF tarafından oluşturulan sorgular şunlar gibi:

SELECT c["City"] FROM root c

Bu tür sorgular Azure Cosmos DB'nin her sonucu aşağıdaki gibi bir JSON nesnesine sarmalamasına neden olur:

[
    {
        "City": "Berlin"
    },
    {
        "City": "México D.F."
    }
]

Sonuçlardan herhangi biri tanımlanmamışsa (örneğin City , özellik belgede yoktu), boş bir belge döndürülür ve EF bu sonuç için döndürülür null .

Yeni davranış

EF Core 9.0'dan başlayarak EF artık değiştiriciyi VALUE sorgulara şu şekilde ekler:

SELECT VALUE c["City"] FROM root c

Bu tür sorgular Azure Cosmos DB'nin sarmalanmadan değerleri doğrudan döndürmesine neden olur:

[
    "Berlin",
    "México D.F."
]

Azure Cosmos DB davranışı, sonuçların dışında değerleri otomatik olarak filtrelemektir undefined ; bu, özelliklerden biri City belgede yoksa, sorgunun biri olmak üzere nulliki sonuç yerine yalnızca tek bir sonuç döndüreceği anlamına gelir.

Neden?

Her sonucun ek bir JSON nesnesine sarmalanması bazı senaryolarda performans düşüşlerine neden olabilir, JSON sonuç yükünü şişirebilir ve Azure Cosmos DB ile çalışmanın doğal yolu değildir.

Risk Azaltıcı Etkenler

Tanımlanmamış sonuçların değerlerini almak null uygulamanız için önemliyse, undefined değerleri yeni null işlecini kullanarak bir hale getirmek içinEF.Functions.Coalesce:

var users = await context.Customer
    .Select(c => EF.Functions.CoalesceUndefined(c.City, null))
    .ToListAsync();

Yanlış çevrilen sorgular artık çevriliyor

İzleme Sorunu #34123

Eski davranış

Daha önce EF tarafından çevrilen sorgular şunlar gibi:

var sessions = await context.Sessions
    .Take(5)
    .Where(s => s.Name.StartsWith("f"))
    .ToListAsync();

Ancak, bu sorgunun SQL çevirisi yanlıştı:

SELECT c
FROM root c
WHERE ((c["Discriminator"] = "Session") AND STARTSWITH(c["Name"], "f"))
OFFSET 0 LIMIT @__p_0

SQL'de yan tümcesi WHERE ve yan tümcelerinden önceOFFSET, ancak yukarıdaki LINQ sorgusunda LIMIT işleç işlecinden Take önce görünür. Sonuç olarak, bu tür sorgular yanlış sonuçlar döndürebilir.

Yeni davranış

EF Core 9.0'dan başlayarak, bu tür sorgular artık çevrilmeyen ve özel durum oluşturulur.

Neden?

Yanlış çeviriler, uygulamanızda bulunması zor hatalar ortaya çıkarabilecek sessiz veri bozulmasına neden olabilir. EF her zaman veri bozulmasına neden olmak yerine önden atarak hızlı bir şekilde başarısız olmayı tercih eder.

Risk Azaltıcı Etkenler

Önceki davranışlardan memnun kaldıysanız ve aynı SQL'i yürütmek istiyorsanız, LINQ işleçlerinin sırasını değiştirmeniz yeterlidir:

var sessions = await context.Sessions
    .Where(s => s.Name.StartsWith("f"))
    .Take(5)
    .ToListAsync();

Ne yazık ki Azure Cosmos DB şu anda SQL alt sorgularındaki ve OFFSET yan tümcelerini desteklememektedirLIMIT. Bu, özgün LINQ sorgusunun düzgün çevirisinin gerektirdiği durumdur.

Düşük etkili değişiklikler

HasIndex şimdi yoksayılmak yerine atar

İzleme Sorunu #34023

Eski davranış

Daha önce, HasIndex çağrısı EF Cosmos DB sağlayıcısı tarafından yoksayıldı.

Yeni davranış

Sağlayıcı şimdi belirtilirse HasIndex atar.

Neden?

Azure Cosmos DB'de tüm özellikler varsayılan olarak dizine eklenir ve dizin oluşturma belirtilmesi gerekmez. Özel dizin oluşturma ilkesi tanımlamak mümkün olsa da, bu şu anda EF tarafından desteklenmez ve EF desteği olmadan Azure Portal üzerinden yapılabilir. HasIndex Aramalar hiçbir şey yapmadığından artık aramalara izin verilmiyor.

Risk Azaltıcı Etkenler

öğesine yapılan tüm çağrıları HasIndexkaldırın.

IncludeRootDiscriminatorInJsonId9.0.0-rc.2'nin ardından olarak yeniden adlandırıldı HasRootDiscriminatorInJsonId

İzleme Sorunu #34717

Eski davranış

IncludeRootDiscriminatorInJsonId API 9.0.0 rc.1'de kullanıma sunulmuştur.

Yeni davranış

EF Core 9.0'ın son sürümü için API olarak yeniden adlandırıldı HasRootDiscriminatorInJsonId

Neden?

başka bir ilgili API yerine ile HasIncludebaşlayacak şekilde yeniden adlandırıldı ve bu nedenle tutarlılık için de yeniden adlandırıldı.

Risk Azaltıcı Etkenler

Kodunuz API'yi IncludeRootDiscriminatorInJsonId kullanıyorsa, bunun yerine başvuru HasRootDiscriminatorInJsonId olarak değiştirmeniz yeterlidir.