Sdílet prostřednictvím

Zásadní změny v EF Core 9 (EF9)

  • Článek

Tato stránka dokumentuje rozhraní API a změny chování, které mají potenciál přerušit stávající aplikace, které se aktualizují z EF Core 8 na EF Core 9. Pokud se aktualizujete ze starší verze EF Core, nezapomeňte si projít dřívější zásadní změny:

Cílová architektura

EF Core 9 cílí na .NET 8. To znamená, že stávající aplikace, které cílí na .NET 8, můžou pokračovat. Aplikace, které cílí na starší verze .NET, .NET Core a .NET Framework, budou muset cílit na .NET 8 nebo .NET 9, aby používaly EF Core 9.

Shrnutí

Poznámka:

Pokud používáte službu Azure Cosmos DB, projděte si následující samostatnou část o zásadních změnách služby Azure Cosmos DB.

Změna způsobující chybu Dopad
K výjimce dojde při aplikaci migrací, pokud existují nevyřízené změny modelu Vysoká
Při použití migrací v explicitní transakci dojde k výjimce. Vysoká
Microsoft.EntityFrameworkCore.Design nebyly nalezeny při použití nástrojů EF Střední
EF.Functions.Unhex() Nyní vrátí hodnotu byte[]? Nízká
Ověřená arity argumentů nullability sqlFunctionExpression Nízká
ToString() Metoda teď vrací prázdný řetězec pro null instance. Nízká
Závislosti sdíleného rozhraní byly aktualizovány na verzi 9.0.x. Nízká

Změny s vysokým dopadem

Pokud existují čekající změny modelu, dojde k výjimce.

Sledovací problém #33732

Staré chování

Pokud má model nevyřízené změny ve srovnání s poslední migrací, po zavolání Migrate se nepoužijí se zbývajícími migracemi.

Nové chování

Od verze EF Core 9.0, pokud má model čekající změny v porovnání s poslední migrací, vyvolá se výjimka při volání dotnet ef database update, Migrate nebo MigrateAsync.

Model pro kontext DbContext obsahuje čekající změny. Před aktualizací databáze přidejte novou migraci. Tuto výjimku lze potlačit nebo protokolovat předáním ID události RelationalEventId.PendingModelChangesWarning do metody ConfigureWarnings v DbContext.OnConfiguring nebo AddDbContext.

Proč

Když po provedení změn modelu zapomenete přidat novou migraci, může být v některých případech obtížné ji diagnostikovat. Nová výjimka zajišťuje, aby model aplikace po použití migrací odpovídal databázi.

Omezení rizik

Existuje několik běžných situací, kdy může být tato výjimka vyvolána.

  • Žádné migrace neexistují. To je běžné, když se databáze aktualizuje jinými prostředky.
    • zmírnění: Pokud neplánujete používat migrace pro správu schématu databáze, odeberte Migrate nebo MigrateAsync výzvu, jinak přidejte migraci.
  • Existuje alespoň jedna migrace, ale chybí snímek modelu. To je běžné pro migrace vytvořené ručně.
    • zmírnění rizik: Přidejte novou migraci pomocí nástrojů EF, tím se aktualizuje snímek modelu.
  • Vývojář model nezměnil, ale je integrovaný nedeterministickým způsobem, který způsobuje, že EF ho rozpozná jako změněný. To je běžné, když se new DateTime(), DateTime.Now, DateTime.UtcNownebo Guid.NewGuid() používají v objektech zadaných do HasData().
    • zmírnění rizik: Přidejte novou migraci, prozkoumejte její obsah a vyhledejte příčinu a nahraďte dynamická data statickou pevně zakódovanou hodnotou v modelu. Po opravení modelu by se měla migrace znovu vytvořit. Pokud je nutné použít dynamická data k počátečnímu nastavení, zvažte použití nového vzoru počátečního .
  • Poslední migrace byla vytvořena pro jiného poskytovatele než ten, který byl použit k aplikaci migrací.
  • Migrace se generují nebo volí dynamicky nahrazením některých služeb EF.

    • zmírnění: Upozornění je v tomto případě falešně pozitivní a mělo by být potlačeno:

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

Pokud váš scénář nespadá pod žádný z výše uvedených případů a přidání nové migrace vytváří pokaždé stejnou migraci nebo prázdnou migraci a přesto dochází k vyvolání výjimky, vytvořte malý projekt pro reprodukci a sdílejte ho s týmem EF vytvořením nového problému.

Výjimka je vyvolána při použití migrací v explicitní transakci.

problém se sledováním č. 17578

Staré chování

K odolnému použití migrací se běžně používal následující model:

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

Nové chování

Počínaje EF Core 9.0 budou volání Migrate a MigrateAsync zahajovat transakci a provádět příkazy pomocí ExecutionStrategy, a pokud vaše aplikace používá výše uvedený vzor, bude vyvolána výjimka:

Vygenerovala se chyba s upozorněním Microsoft.EntityFrameworkCore.Migrations.MigrationsUserTransactionWarning: Transakce byla spuštěna před použitím migrací. Tím zabráníte získání zámku databáze, a proto databáze nebude chráněna před souběžnými aplikacemi migrace. Transakce a strategie provádění jsou již spravovány EF dle potřeby. Odeberte externí transakci. Tuto výjimku lze potlačit nebo protokolovat předáním ID události RelationalEventId.MigrationsUserTransactionWarning do metody ConfigureWarnings v DbContext.OnConfiguring nebo AddDbContext.

Proč

Použití explicitní transakce brání získání zámku databáze, a proto databáze nebude chráněna před souběžnými aplikacemi migrace, omezuje také EF na to, jak může spravovat transakce interně.

Omezení rizik

Pokud uvnitř transakce existuje pouze jedno volání databáze, odeberte externí transakci a ExecutionStrategy:

await dbContext.Database.MigrateAsync(cancellationToken);

Jinak pokud váš scénář vyžaduje explicitní transakci a máte k dispozici jiný mechanismus, abyste zabránili souběžné migraci aplikace, ignorujte upozornění:

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

Změny se středním dopadem

Microsoft.EntityFrameworkCore.Design nebyla nalezena při použití nástrojů EF

Problém se sledováním #35265

Staré chování

Dříve bylo nutné, aby nástroje EF byly na Microsoft.EntityFrameworkCore.Design odkazovány následujícím způsobem.

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

Nové chování

Počínaje sadou .NET SDK 9.0.200 se při vyvolání nástroje EF vyvolá výjimka:

Nelze načíst soubor nebo sestavení Microsoft.EntityFrameworkCore.Design, Culture=neutral, PublicKeyToken=null. Systém nemůže najít zadaný soubor.

Proč

Nástroje EF závisely na nezdokumentovaném chování sady .NET SDK, které způsobilo zahrnutí privátních prostředků do vygenerovaného souboru .deps.json. Toto bylo opraveno v rámci SDK#45259. Bohužel změna EF, která toto řeší, nesplňuje podmínky údržby pro EF 9.0.x, proto bude opraveno v EF 10.

Omezení rizik

Jako alternativní řešení před vydáním EF 10 můžete označit odkaz na sestavení Design jako publikovatelný:

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

To ho zahrne do vygenerovaného souboru .deps.json, ale má vedlejší vliv na kopírování Microsoft.EntityFrameworkCore.Design.dll do výstupních a publikovaných složek.

Změny s nízkým dopadem

EF.Functions.Unhex() Nyní vrátí hodnotu byte[]?

Problém se sledováním č. 33864

Staré chování

Funkce EF.Functions.Unhex() byla dříve opatřena poznámkami k vrácení byte[].

Nové chování

Počínaje EF Core 9.0 je unhex() nyní anotován k vrácení byte[]?.

Proč

Unhex() se přeloží na funkci SQLite unhex , která vrátí hodnotu NULL pro neplatné vstupy. V důsledku toho se Unhex()null vrátí pro tyto případy v rozporu s poznámkou.

Omezení rizik

Pokud jste si jisti, že textový obsah předaný Unhex() představuje platný šestnáctkový řetězec, můžete jednoduše přidat operátor null-forgiving jako kontrolní výraz, že vyvolání nikdy nevrátí hodnotu null:

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

V opačném případě přidejte kontroly za běhu na návratové hodnotě Unhex().

Ověřená arity argumentů nullability sqlFunctionExpression

Problém se sledováním č. 33852

Staré chování

Dříve bylo možné vytvořit argumenty SqlFunctionExpression s jiným počtem argumentů a šíření hodnot null.

Nové chování

Od EF Core 9.0 teď EF vyvolá výjimku, pokud se počet argumentů a argumenty šíření null neshodují.

Proč

Nemá odpovídající počet argumentů a argumenty šíření hodnot null můžou vést k neočekávanému chování.

Omezení rizik

Ujistěte se, argumentsPropagateNullability že má stejný počet prvků jako .arguments Pokud je pochyb o použití false argumentu nullability.

ToString() Metoda teď vrací prázdný řetězec pro null instance.

Problém se sledováním č. 33941

Staré chování

Dříve ef vrátil nekonzistentní výsledky pro metodu ToString() , když byla nullhodnota argumentu . Například ToString() u vlastnosti s vrácenou bool?nullhodnotou , ale pro výrazy, null jejichž hodnota nebyla vrácena bool?null.True Chování bylo také nekonzistentní pro jiné datové typy, například ToString() u null výčtu hodnot vrátil prázdný řetězec.

Nové chování

Počínaje EF Core 9.0 ToString() metoda nyní konzistentně vrací prázdný řetězec ve všech případech, když je nullhodnota argumentu .

Proč

Staré chování bylo nekonzistentní v různých datových typech a situacích, stejně jako není v souladu s chováním jazyka C#.

Omezení rizik

Pokud se chcete vrátit k původnímu chování, přepište dotaz odpovídajícím způsobem:

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

Závislosti sdíleného rozhraní byly aktualizovány na verzi 9.0.x.

Staré chování

Aplikace využívající Microsoft.NET.Sdk.Web sadu SDK a cílící na net8.0 by přeložily balíčky jako System.Text.Json, Microsoft.Extensions.Caching.MemoryMicrosoft.Extensions.Configuration.AbstractionsMicrosoft.Extensions.Logging, a Microsoft.Extensions.DependencyModel ze sdílené architektury, takže tato sestavení by se s aplikací normálně nenasadila.

Nové chování

I když EF Core 9.0 stále podporuje net8.0, nyní odkazuje na verze System.Text.Json9.0.x , Microsoft.Extensions.Caching.Memorya Microsoft.Extensions.Configuration.AbstractionsMicrosoft.Extensions.LoggingMicrosoft.Extensions.DependencyModel. Aplikace, které cílí na net8.0, nebudou moct využívat sdílenou architekturu, aby se zabránilo nasazení těchto sestavení.

Proč

Odpovídající verze závislostí obsahují nejnovější opravy zabezpečení a jejich použití zjednodušuje model údržby pro EF Core.

Omezení rizik

Změňte aplikaci na cíl net9.0, abyste získali předchozí chování.

Zásadní změny ve službě Azure Cosmos DB

Rozsáhlá práce se stala lepším poskytovatelem služby Azure Cosmos DB ve verzi 9.0. Tyto změny zahrnují řadu zásadních změn s velkým dopadem; Pokud upgradujete existující aplikaci, pečlivě si přečtěte následující informace.

Změna způsobující chybu Dopad
Diskriminující vlastnost je nyní pojmenována $type místo Discriminator Vysoká
Vlastnost id již ve výchozím nastavení neobsahuje diskriminátor. Vysoká
vlastnost id JSON se mapuje na klíč Vysoká
Synchronizace vstupně-výstupních operací prostřednictvím poskytovatele služby Azure Cosmos DB se už nepodporuje. Střední
Dotazy SQL teď musí projektovat hodnoty JSON přímo Střední
Nedefinované výsledky se teď automaticky filtrují z výsledků dotazu. Střední
Nesprávně přeložené dotazy se už nepřekládají Střední
HasIndex Teď se místo ignorování vyvolá Nízká
IncludeRootDiscriminatorInJsonId byl přejmenován na HasRootDiscriminatorInJsonId verzi 9.0.0-rc.2. Nízká

Změny s vysokým dopadem

Diskriminující vlastnost je nyní pojmenována $type místo Discriminator

Problém se sledováním č. 34269

Staré chování

EF automaticky přidá diskriminující vlastnost do dokumentů JSON k identifikaci typu entity, který dokument představuje. V předchozích verzích EF se tato vlastnost JSON používala k pojmenování Discriminator ve výchozím nastavení.

Nové chování

Počínaje EF Core 9.0 se ve výchozím nastavení volá $type diskriminující vlastnost. Pokud máte existující dokumenty ve službě Azure Cosmos DB z předchozích verzí EF, použijí se staré Discriminator pojmenování a po upgradu na EF 9.0 se dotazy na tyto dokumenty nezdaří.

Proč

Nově vznikající praxe JSON používá $type vlastnost ve scénářích, ve kterých je potřeba identifikovat typ dokumentu. Například. Net System.Text.Json také podporuje polymorfismus, který se používá $type jako výchozí diskriminující název vlastnosti (docs). Abychom se shodovali se zbytkem ekosystému a usnadnili spolupráci s externími nástroji, výchozí nastavení se změnilo.

Omezení rizik

Nejjednodušším zmírněním rizik je jednoduše nakonfigurovat název diskriminující vlastnosti tak, aby byl Discriminator, stejně jako předtím:

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

Když to uděláte pro všechny typy entit nejvyšší úrovně, ef se bude chovat stejně jako předtím.

Pokud chcete, můžete v tomto okamžiku aktualizovat také všechny dokumenty tak, aby používaly nové $type pojmenování.

Vlastnost id teď ve výchozím nastavení obsahuje pouze vlastnost klíče EF.

Problém se sledováním č. 34179

Staré chování

Systém EF dříve vložil do vlastnosti dokumentu diskriminující hodnotu typu id entity. Pokud jste například uložili Blog typ entity s Id vlastností obsahující 8, vlastnost JSON id by obsahovala Blog|8.

Nové chování

Od EF Core 9.0 už vlastnost JSON id neobsahuje diskriminující hodnotu a obsahuje pouze hodnotu vlastnosti klíče. Ve výše uvedeném příkladu by vlastnost JSON id jednoduše byla 8. Pokud máte existující dokumenty ve službě Azure Cosmos DB z předchozích verzí EF, mají tyto dokumenty v vlastnosti JSON id diskriminující hodnotu a po upgradu na EF 9.0 se dotazy na tyto dokumenty nezdaří.

Proč

Vzhledem k tomu, že vlastnost JSON id musí být jedinečná, byla k ní dříve přidána diskriminátor, aby mohly existovat různé entity se stejnou hodnotou klíče. To například umožňuje mít vlastnost Blog i Post s Id vlastností obsahující hodnotu 8 ve stejném kontejneru a oddílu. To se lépe zarovná se vzory modelování dat relačních databází, kde se každý typ entity mapuje na vlastní tabulku, a proto má vlastní prostor klíčů.

EF 9.0 obecně změnil mapování tak, aby bylo lépe v souladu s běžnými postupy a očekáváními NoSQL služby Azure Cosmos DB, a nikoli tak, aby odpovídalo očekáváním uživatelů pocházejících z relačních databází. Kromě toho je u id externích nástrojů a systémů obtížnější pracovat s dokumenty JSON generovanými systémem EF, protože tyto externí systémy obecně neznají diskriminující hodnoty EF, které jsou ve výchozím nastavení odvozené z typů .NET.

Omezení rizik

Nejjednodušším zmírněním rizik je jednoduše nakonfigurovat EF tak, aby zahrnovala diskriminátor ve vlastnosti JSON id jako předtím. Pro tento účel byla zavedena nová možnost konfigurace:

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

Když to uděláte pro všechny typy entit nejvyšší úrovně, ef se bude chovat stejně jako předtím.

Pokud chcete, můžete v tomto okamžiku aktualizovat také všechny dokumenty a přepsat jejich vlastnost JSON id . Mějte na paměti, že to je možné jenom v případě, že entity různých typů nesdílely stejnou hodnotu ID ve stejném kontejneru.

Vlastnost JSON id je mapována na klíč.

Problém se sledováním č. 34179

Staré chování

Ef dříve vytvořil stínovou vlastnost mapovanou na vlastnost JSON id, pokud nebyla některá z těchto vlastností namapována na id explicitně.

Nové chování

Od EF Core 9 se klíčová vlastnost mapuje na vlastnost JSON id podle konvence, pokud je to možné. To znamená, že vlastnost klíče již nebude v dokumentu uchována pod jiným názvem se stejnou hodnotou, proto kód, který není EF a pracuje s dokumenty a spoléhá na tuto vlastnost, již nebude fungovat správně.

Proč

EF 9.0 obecně změnil mapování tak, aby lépe odpovídalo běžným postupům a očekáváním NoSQL ve službě Azure Cosmos DB. A není běžné uložit hodnotu klíče dvakrát v dokumentu.

Omezení rizik

Pokud chcete zachovat chování EF Core 8, nejjednodušším řešením je použít novou možnost konfigurace, která byla zavedena pro tento účel:

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

Když to uděláte pro všechny typy entit nejvyšší úrovně, ef se bude chovat stejně jako předtím. Nebo ho můžete použít pro všechny typy entit v modelu jedním voláním:

modelBuilder.HasShadowIds();

Změny se středním dopadem

Synchronizace vstupně-výstupních operací prostřednictvím poskytovatele služby Azure Cosmos DB se už nepodporuje.

Problém se sledováním č. 32563

Staré chování

Dříve volání synchronních metod, jako je ToList nebo SaveChanges by způsobilo synchronní blokování EF Core při .GetAwaiter().GetResult() provádění asynchronních volání se sadou SDK služby Azure Cosmos DB. To může mít za následek zablokování.

Nové chování

Od EF Core 9.0 teď EF při pokusu o použití synchronních vstupně-výstupních operací ve výchozím nastavení vyvolá výchozí hodnotu. Zpráva o výjimce :Azure Cosmos DB nepodporuje synchronní vstupně-výstupní operace. Ujistěte se, že pro přístup ke službě Azure Cosmos DB používáte a správně očekáváte pouze asynchronní metody. Další https://aka.ms/ef-cosmos-nosync informace najdete tady.

Proč

Synchronní blokování asynchronních metod může vést k zablokování a sada SDK služby Azure Cosmos DB podporuje pouze asynchronní metody.

Omezení rizik

V EF Core 9.0 může být chyba potlačena:

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

To znamená, že aplikace by měly přestat používat synchronizační rozhraní API se službou Azure Cosmos DB, protože tato funkce není podporována sadou SDK služby Azure Cosmos DB. Možnost potlačit výjimku se odebere v budoucí verzi EF Core, po které jedinou možností bude použití asynchronních rozhraní API.

Dotazy SQL teď musí projektovat hodnoty JSON přímo

Problém se sledováním č. 25527

Staré chování

Dříve vygenerované dotazy EF, například následující:

SELECT c["City"] FROM root c

Tyto dotazy způsobí, že Azure Cosmos DB zabalí každý výsledek do objektu JSON následujícím způsobem:

[
    {
        "City": "Berlin"
    },
    {
        "City": "México D.F."
    }
]
Nové chování

Od EF Core 9.0 teď EF přidá VALUE modifikátor do dotazů následujícím způsobem:

SELECT VALUE c["City"] FROM root c

Tyto dotazy způsobují, že Azure Cosmos DB vrátí hodnoty přímo, aniž by bylo zabaleno:

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

Pokud vaše aplikace využívá dotazy SQL, tyto dotazy se pravděpodobně po upgradu na EF 9.0 přeruší, protože VALUE neobsahují modifikátor.

Proč

Zabalení každého výsledku do dalšího objektu JSON může způsobit snížení výkonu v některých scénářích, nafoukne datovou část výsledku JSON a není přirozeným způsobem, jak pracovat se službou Azure Cosmos DB.

Omezení rizik

Pokud chcete tento problém zmírnit, jednoduše přidejte VALUE modifikátor do projekcí dotazů SQL, jak je znázorněno výše.

Nedefinované výsledky se teď automaticky filtrují z výsledků dotazu.

Problém se sledováním č. 25527

Staré chování

Dříve vygenerované dotazy EF, například následující:

SELECT c["City"] FROM root c

Tyto dotazy způsobí, že Azure Cosmos DB zabalí každý výsledek do objektu JSON následujícím způsobem:

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

Pokud některý z výsledků nebyl definován (např. City vlastnost v dokumentu chybí), vrátil se prázdný dokument a ef by se pro tento výsledek vrátil null .

Nové chování

Od EF Core 9.0 teď EF přidá VALUE modifikátor do dotazů následujícím způsobem:

SELECT VALUE c["City"] FROM root c

Tyto dotazy způsobují, že Azure Cosmos DB vrátí hodnoty přímo, aniž by bylo zabaleno:

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

Chování služby Azure Cosmos DB spočívá v automatickém filtrování undefined hodnot z výsledků. To znamená, že pokud v dokumentu chybí jedna z City vlastností, dotaz by vrátil pouze jeden výsledek, a ne dva výsledky, přičemž jeden je null.

Proč

Zabalení každého výsledku do dalšího objektu JSON může způsobit snížení výkonu v některých scénářích, nafoukne datovou část výsledku JSON a není přirozeným způsobem, jak pracovat se službou Azure Cosmos DB.

Omezení rizik

Pokud je pro vaši aplikaci důležité získat null hodnoty pro nedefinované výsledky, sloučíte undefined je s null použitím nového EF.Functions.Coalesce operátoru:

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

Nesprávně přeložené dotazy se už nepřekládají

Problém se sledováním č. 34123

Staré chování

Dříve ef přeložené dotazy, jako jsou například následující:

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

Překlad SQL pro tento dotaz však nebyl správný:

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

V SQL WHERE se klauzule vyhodnocuje předOFFSET klauzulí a LIMIT klauzulí, ale ve výše uvedeném Take dotazu LINQ se operátor zobrazí před operátorem Where . V důsledku toho by tyto dotazy mohly vrátit nesprávné výsledky.

Nové chování

Od EF Core 9.0 se tyto dotazy už nepřekládají a vyvolá se výjimka.

Proč

Nesprávné překlady můžou způsobit tiché poškození dat, což může ve vaší aplikaci způsobit těžko zjistitelné chyby. EF vždy dává přednost selháním rychlému vyvolání fronty, a ne k případnému poškození dat.

Omezení rizik

Pokud jste byli spokojení s předchozím chováním a chtěli byste spustit stejný SQL, jednoduše prohodíte pořadí operátorů LINQ:

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

Služba Azure Cosmos DB v současné době nepodporuje OFFSET klauzule a LIMIT klauzule v poddotazech SQL, což je to, co vyžaduje správný překlad původního dotazu LINQ.

Změny s nízkým dopadem

HasIndex Teď se místo ignorování vyvolá

Problém se sledováním č. 34023

Staré chování

Dříve zprostředkovatel SLUŽBY EF Cosmos DB ignoroval volání, která HasIndex se mají ignorovat.

Nové chování

Zprostředkovatel nyní vyvolá, pokud HasIndex je zadán.

Proč

Ve službě Azure Cosmos DB se ve výchozím nastavení indexují všechny vlastnosti a není nutné zadaná žádná indexování. I když je možné definovat vlastní zásady indexování, ef to v současné době nepodporuje a dá se provést prostřednictvím webu Azure Portal bez podpory EF. Vzhledem k tomu HasIndex , že hovory nic nedělá, už nejsou povolené.

Omezení rizik

Odeberte všechna volání .HasIndex

IncludeRootDiscriminatorInJsonId byl přejmenován na HasRootDiscriminatorInJsonId verzi 9.0.0-rc.2.

Problém se sledováním č. 34717

Staré chování

Rozhraní IncludeRootDiscriminatorInJsonId API bylo zavedeno ve verzi 9.0.0 rc.1.

Nové chování

V konečné verzi EF Core 9.0 se rozhraní API přejmenovalo na HasRootDiscriminatorInJsonId

Proč

Jiné související rozhraní API bylo přejmenováno tak, aby začínalo Has namísto Include, a proto se tento rozhraní přejmenoval také na konzistenci.

Omezení rizik

Pokud váš kód používá IncludeRootDiscriminatorInJsonId rozhraní API, jednoduše ho změňte na odkaz HasRootDiscriminatorInJsonId .