Eğitim
Öğrenme yolu
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
EF Core 9'da (EF9) hataya neden olan değişiklikler
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:
- EF Core 8'de hataya neden olan değişiklikler
- EF Core 7'de hataya neden olan değişiklikler
- EF Core 6'da hataya neden olan değişiklikler
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.
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 |
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.
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.
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.
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
MigrateveyaMigrateAsyncçağrısını kaldırın, aksi takdirde bir geçiş ekleyin.
-
Azaltma: Veritabanı şemasını yönetmek için geçişleri kullanmayı planlamıyorsanız
- 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 nesnelerdeDateTime.Now,DateTime.UtcNow,Guid.NewGuid()veyaHasData()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.
-
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
- Son geçiş, geçişleri uygulamak için kullanılan sağlayıcıdan farklı bir sağlayıcı için oluşturuldu.
- 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.
Geçişleri dayanıklı bir şekilde uygulamak için yaygın olarak aşağıdaki desen kullanılmıştır:
C#
await dbContext.Database.CreateExecutionStrategy().ExecuteAsync(async () =>
{
await using var transaction = await dbContext.Database.BeginTransactionAsync(cancellationToken);
await dbContext.Database.MigrateAsync(cancellationToken);
await transaction.CommitAsync(cancellationToken);
});
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.
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.
İşlemin içinde yalnızca bir veritabanı çağrısı varsa dış işlemi kaldırın ve ExecutionStrategy:
C#
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:
C#
options.ConfigureWarnings(w => w.Ignore(RelationalEventId.MigrationsUserTransactionWarning))
Önceden EF araçlarına aşağıdaki şekilde başvurulmak Microsoft.EntityFrameworkCore.Design gerekiyordu.
XML
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="*.0.0">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
.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.
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.
EF 10 yayımlanmadan önce geçici bir çözüm olarak, Design derleme başvurusunu yayımlanabilir olarak belirtebilirsiniz:
XML
<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.
İşleve EF.Functions.Unhex() daha önce döndürülmesi byte[]için ek açıklama eklendi.
EF Core 9.0'dan başlayarak Unhex() artık döndürülmesi byte[]?için ek açıklama eklenmiştir.
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 .
öğ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:
C#
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.
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ü.
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.
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.
öğ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 .
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ü.
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.
Eski davranış, farklı veri türleri ve durumlarda tutarsızdı ve C# davranışıyla uyumlu değildi.
Eski davranışa dönmek için sorguyu uygun şekilde yeniden yazın:
C#
var newBehavior = context.Entity.Select(x => x.NullableBool.ToString());
var oldBehavior = context.Entity.Select(x => x.NullableBool == null ? null : x.NullableBool.ToString());
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.
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.
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.
Önceki davranışı elde etmek için uygulamanızı net9.0 hedefine değiştirin.
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.
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 .
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.
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.
En kolay azaltma, ayrıştırıcı özelliğinin adını aşağıdaki gibi olacak şekilde yapılandırmaktır Discriminator:
C#
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.
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.
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.
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.
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:
C#
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.
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.
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.
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.
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:
C#
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:
C#
modelBuilder.HasShadowIds();
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.
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 .
Zaman uyumsuz yöntemlerde zaman uyumlu engelleme kilitlenmeye neden olabilir ve Azure Cosmos DB SDK'sı yalnızca zaman uyumsuz yöntemleri destekler.
EF Core 9.0'da hata şu şekilde gizlenebilir:
C#
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.
Daha önce EF tarafından oluşturulan sorgular şunlar gibi:
SQL
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:
JSON
[
{
"City": "Berlin"
},
{
"City": "México D.F."
}
]
EF Core 9.0'dan başlayarak EF artık değiştiriciyi VALUE sorgulara şu şekilde ekler:
SQL
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:
JSON
[
"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.
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.
Azaltmak için, değiştiriciyi VALUE yukarıda gösterildiği gibi SQL sorgularınızın projeksiyonlarına eklemeniz yeterlidir.
Daha önce EF tarafından oluşturulan sorgular şunlar gibi:
SQL
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:
JSON
[
{
"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 .
EF Core 9.0'dan başlayarak EF artık değiştiriciyi VALUE sorgulara şu şekilde ekler:
SQL
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:
JSON
[
"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.
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.
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:
C#
var users = await context.Customer
.Select(c => EF.Functions.CoalesceUndefined(c.City, null))
.ToListAsync();
Daha önce EF tarafından çevrilen sorgular şunlar gibi:
C#
var sessions = await context.Sessions
.Take(5)
.Where(s => s.Name.StartsWith("f"))
.ToListAsync();
Ancak, bu sorgunun SQL çevirisi yanlıştı:
SQL
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.
EF Core 9.0'dan başlayarak, bu tür sorgular artık çevrilmeyen ve özel durum oluşturulur.
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.
Ö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:
C#
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.
Daha önce, HasIndex çağrısı EF Cosmos DB sağlayıcısı tarafından yoksayıldı.
Sağlayıcı şimdi belirtilirse HasIndex atar.
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.
öğ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
IncludeRootDiscriminatorInJsonId API 9.0.0 rc.1'de kullanıma sunulmuştur.
EF Core 9.0'ın son sürümü için API olarak yeniden adlandırıldı HasRootDiscriminatorInJsonId
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ı.
Kodunuz API'yi IncludeRootDiscriminatorInJsonId kullanıyorsa, bunun yerine başvuru HasRootDiscriminatorInJsonId olarak değiştirmeniz yeterlidir.
GitHub'da bizimle işbirliği yapın
Bu içeriğin kaynağı GitHub'da bulunabilir; burada ayrıca sorunları ve çekme isteklerini oluşturup gözden geçirebilirsiniz. Daha fazla bilgi için katkıda bulunan kılavuzumuzu inceleyin.
.NET geri bildirimi
.NET, açık kaynak bir projedir. Geri bildirim sağlamak için bir bağlantı seçin: