Megosztás a következőn keresztül:

Az EF Core 9 (EF9) kompatibilitástörő változásai

  • Cikk

Ez a lap olyan API- és viselkedésváltozásokat dokumentál, amelyek képesek megszakítani az EF Core 8-ról EF Core 9-re frissített meglévő alkalmazásokat. Mindenképpen tekintse át a korábbi kompatibilitástörő módosításokat, ha az EF Core egy korábbi verziójáról frissít:

Cél-keretrendszer

Az EF Core 9 a .NET 8-at célozza meg. Ez azt jelenti, hogy a .NET 8-at megcélzott meglévő alkalmazások továbbra is megtehetik. A régebbi .NET-, .NET Core- és .NET-keretrendszerverziókat megcélzó alkalmazásoknak .NET 8 vagy .NET 9-et kell céloznia az EF Core 9 használatához.

Összefoglalás

Jegyzet

Ha az Azure Cosmos DB-t használja, kérjük, tekintse meg az alábbi külön szakaszt az Azure Cosmos DB jelentős változásairól.

Kompatibilitástörő változás hatás
Migrálás alkalmazásakor kivétel lép fel, ha függőben lévő modellmódosítások vannak Magas
Kivétel dobódik, amikor migráció történik egy explicit tranzakcióban. Magas
Microsoft.EntityFrameworkCore.Design nem található ef-eszközök használatakor Közepes
EF.Functions.Unhex() most byte[]? Alacsony
Az SqlFunctionExpression nullabilitási argumentumainak aritása ellenőrizve lett Alacsony
ToString() metódus most üres stringet ad vissza a null példányoknál Alacsony
A megosztott keretrendszer függőségei frissítve lettek 9.0.x verzióra Alacsony

Nagy hatású változások

Kivétel lép fel az áttelepítések alkalmazásakor, ha függőben lévő modellmódosítások vannak

nyomon követési probléma #33732

Régi viselkedés

Ha a modell az utolsó migráláshoz képest függő változtatásokat tartalmaz, akkor Migrate meghívásakor ezek a változtatások nem kerülnek alkalmazásra a többi migrációval együtt.

Új viselkedés

Az EF Core 9.0-tól kezdődően, ha a modellnek vannak függőben lévő változtatásai a legutóbbi migrációhoz képest, kivétel kerül kilépésre, amikor a dotnet ef database update, Migrate vagy MigrateAsync függvényhívás megtörténik.

A "DbContext" környezet modellje függőben lévő módosításokat hajt végre. Új migrálás hozzáadása az adatbázis frissítése előtt. Ezt a kivételt a "RelationalEventId.PendingModelChangesWarning" eseményazonosítónak a DbContext.OnConfiguring vagy az AddDbContext metódus "ConfigureWarnings" metódusára való átadásával lehet letiltani vagy naplózni.

Miért

Gyakori hiba, hogy elfelejt új migrálást hozzáadni a modellmódosítások elvégzése után, amely bizonyos esetekben nehezen diagnosztizálható. Az új kivétel biztosítja, hogy az alkalmazás modellje megegyezik az adatbázissal az áttelepítések alkalmazása után.

Enyhítések

Ez a kivétel több gyakori esetet is okozhat:

  • Egyáltalán nincsenek áttelepítések. Ez gyakori, ha az adatbázis más eszközökkel frissül.
    • mérséklés: Ha nem tervezi az adatbázisséma kezeléséhez a migrációt, távolítsa el a Migrate vagy MigrateAsync hívást, ellenkező esetben adjon hozzá egy migrációt.
  • Legalább egy migrálás van, de a modell pillanatképe hiányzik. Ez gyakori a manuálisan létrehozott áttelepítések esetében.
    • Enyhítés: Adjon hozzá egy új migrációt az EF-eszközzel, ez frissíteni fogja a modell pillanatképét.
  • A modellt nem módosította a fejlesztő, de nem determinisztikus módon lett felépítve, így az EF módosítottként észleli. Ez gyakran előfordul, amikor a new DateTime(), DateTime.Now, DateTime.UtcNowvagy Guid.NewGuid() olyan objektumokban van használva, amelyeket a HasData()-hez adtak.
    • kockázatcsökkentési: Adjon hozzá egy új migrálást, vizsgálja meg annak tartalmát az ok megkereséséhez, és cserélje le a dinamikus adatokat egy statikus, merevlemezes értékre a modellben. A migrálást a modell kijavítása után újra létre kell hozni. Ha dinamikus adatokat kell használni a vetéshez, fontolja meg az új vetésmintátHasData()helyett.
  • Az utolsó migráció egy másik szolgáltató számára készült, mint amit a migrációk alkalmazásához használtak.
  • A rendszer dinamikusan hozza létre vagy választja ki a migrálásokat néhány EF-szolgáltatás lecserélésével.

    • Kockázatcsökkentés: A figyelmeztetés ebben az esetben hamis pozitív, ezért figyelmen kívül kell hagyni.

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

Ha a forgatókönyv nem tartozik a fenti esetek egyikébe sem, és egy új migráció hozzáadása minden alkalommal ugyanazt a migrációt hozza létre, vagy egy üres migrációt, és a kivétel továbbra is fennáll, akkor hozzon létre egy kis reprodukciós projektet, és ossza meg az EF-csapattal egy új hibajegy.

Kivétel lép fel a migrálás explicit tranzakcióban való alkalmazásakor

nyomon követési probléma #17578

Régi viselkedés

A migrálások rugalmas alkalmazásához gyakran az alábbi mintát használták:

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

Új viselkedés

Az EF Core 9.0-tól kezdve Migrate és MigrateAsync hívások elindítanak egy tranzakciót, és végrehajtják a parancsokat egy ExecutionStrategy használatával, és ha az alkalmazás a fenti mintát használja, kivétel jelenik meg:

Hiba történt a "Microsoft.EntityFrameworkCore.Migrations.Migrations.MigrationsUserTransactionWarning" figyelmeztetésnél: A tranzakció az áttelepítések alkalmazása előtt indult el. Ez megakadályozza az adatbázis-zárolás beszerzését, ezért az adatbázis nem lesz védve az egyidejű migrálási alkalmazásoktól. A tranzakciókat és a végrehajtási stratégiát az EF már szükség szerint kezeli. Távolítsa el a külső tranzakciót. Ez a kivétel letiltható vagy naplózható a "RelationalEventId.MigrationsUserTransactionWarning" eseményazonosítónak a DbContext.OnConfiguring vagy az AddDbContext "ConfigureWarnings" metódusnak való átadásával.

Miért

Explicit tranzakció használata megakadályozza az adatbázis-zárolás beszerzését, ezért az adatbázis nem lesz védve az egyidejű migrálási alkalmazásoktól, és az EF-t is korlátozza, hogy hogyan kezelheti a tranzakciókat belsőleg.

Enyhítések

Ha a tranzakción belül csak egy adatbázis-hívás található, távolítsa el a külső tranzakciót, és ExecutionStrategy:

await dbContext.Database.MigrateAsync(cancellationToken);

Ellenkező esetben, ha a forgatókönyv explicit tranzakciót igényel, és más mechanizmussal is rendelkezik az egyidejű migrálási alkalmazás megakadályozásához, hagyja figyelmen kívül a figyelmeztetést:

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

Közepes hatású változások

Az „Microsoft.EntityFrameworkCore.Design” nem található az EF-eszközök használatakor.

nyomon követési probléma #35265

Régi viselkedés

Korábban az EF-eszközökre a következő módon kellett „Microsoft.EntityFrameworkCore.Design”-ra hivatkozni.

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

Új viselkedés

A .NET SDK 9.0.200-tól kezdve kivétel történik egy EF-eszköz meghívásakor:

Nem sikerült betölteni a "Microsoft.EntityFrameworkCore.Design, Culture=neutral, PublicKeyToken=null" fájlt vagy szerelvényt. A megadott fájl nem található.

Miért

Az EF-eszközök a .NET SDK nem dokumentált viselkedésére támaszkodtak, amely miatt a privát eszközök bekerültek a létrehozott .deps.json fájlba. Ez a sdk#45259-ben lett javítva. Sajnos az EF-változás, amely ezt figyelembe veszi, nem felel meg az EF 9.0.x karbantartási sávjának, ezért az EF 10-ben lesz javítva.

Enyhítések

Átmeneti megoldásként, amíg az EF 10 meg nem jelenik, megjelölheti a Design összeállítási hivatkozást közzétehetőként:

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

Ez bekerül a létrehozott .deps.json fájlba, de az a mellékhatása van, hogy a Microsoft.EntityFrameworkCore.Design.dll a kimeneti és közzétételi mappákba is átmásolódik.

Kis hatású módosítások

EF.Functions.Unhex() most visszatéríti byte[]?

Nyomon követési probléma #33864

Régi viselkedés

A EF.Functions.Unhex() függvény korábban a byte[]visszatérésére volt megjegyzéssel ellátva.

Új viselkedés

Az EF Core 9.0-tól kezdve a Unhex() mostantól úgy lett jelölve, hogy byte[]?-t adjon vissza.

Miért

Unhex() az SQLite unhex függvényre lesz lefordítva, amely null értéket ad vissza érvénytelen bemenetek esetén. Ennek eredményeképpen Unhex() adott vissza null ezekben az esetekben, megsértve a jelölést.

Enyhítések

Ha biztos abban, hogy a Unhex()-nak átadott szöveges tartalom érvényes hexadecimális sztringet jelöl, egyszerűen hozzáadhatja a nullt elhagyó operátort biztosítékul, hogy a meghívás soha nem ad vissza null értéket.

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

Ellenkező esetben null értékű futásidejű ellenőrzéseket adhat hozzá a Unhex() visszatérési értékéhez.

Az SqlFunctionExpression nullability argumentumainak aritása érvényesítve

nyomon követési probléma #33852

Régi viselkedés

Korábban lehetőség volt SqlFunctionExpression-t létrehozni különböző számú argumentummal és nullállhatósági terjesztési argumentummal.

Új viselkedés

Az EF Core 9.0-s verziójától kezdve az EF akkor dob, ha az argumentumok és a nullíthatóság propagálási argumentumainak száma nem egyezik.

Miért

Ha az argumentumok száma és a nullállapot terjesztési argumentumok nem egyeznek meg, az váratlan viselkedéshez vezethet.

Enyhítések

Győződjön meg arról, hogy a argumentsPropagateNullability azonos számú elemből áll, mint a arguments. Ha kétségei vannak, használja a false nullabilitási argumentumot.

ToString() metódus mostantól üres sztringet ad vissza null példányokhoz

nyomon követési probléma #33941

Régi viselkedés

Korábban az EF inkonzisztens eredményeket adott vissza a ToString() metódushoz, amikor az argumentum értéke nullvolt. Például ToString()bool?nullvisszaadott null értékkel rendelkező tulajdonságon, de olyan nem tulajdonságú bool? kifejezéseknél, amelyek értéke null visszaadott True. A viselkedés más adattípusok esetében is inkonzisztens volt, például a ToString()null érték enumerációnál üres karakterláncot adott vissza.

Új viselkedés

Az EF Core 9.0-tól kezdve a ToString() metódus mostantól következetesen üres sztringet ad vissza minden olyan esetben, amikor az argumentum értéke null.

Miért

A régi viselkedés inkonzisztens volt különböző adattípusokban és helyzetekben, valamint nem volt összhangban a C# viselkedési.

Enyhítések

A régi viselkedésre való visszatéréshez írja át a lekérdezést a következő módon:

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

A megosztott keretrendszer függőségei 9.0.x-ra frissültek

Régi viselkedés

A Microsoft.NET.Sdk.Web SDK-t és a net8.0-t használó alkalmazások feloldanák az olyan csomagokat, mint a System.Text.Json, Microsoft.Extensions.Caching.Memory, Microsoft.Extensions.Configuration.Abstractions, Microsoft.Extensions.Logging és Microsoft.Extensions.DependencyModel a megosztott keretrendszerből, így ezek a szerelvények általában nem lesznek üzembe helyezve az alkalmazással.

Új viselkedés

Bár az EF Core 9.0 továbbra is támogatja a net8.0-t , a System.Text.Json, Microsoft.Extensions.Caching.Memory, Microsoft.Extensions.Configuration.Abstractions, Microsoft.Extensions.Logging és Microsoft.Extensions.DependencyModel9.0.x verziójára hivatkozik . A net8.0-t célzó alkalmazások nem fogják tudni kihasználni a megosztott keretrendszert ezen szerelvények üzembe helyezésének elkerülése érdekében.

Miért

Az egyező függőségi verziók tartalmazzák a legújabb biztonsági javításokat, és használatuk leegyszerűsíti az EF Core karbantartási modelljét.

Enyhítések

Állítsa be az alkalmazást a net9.0 célplatformra a korábbi működés visszaállításához.

Az Azure Cosmos DB kompatibilitástörő változásai

Az Azure Cosmos DB szolgáltató 9.0-s verziójának javítása érdekében kiterjedt munkát végeztek. A módosítások közé tartozik számos nagy hatású kompatibilitástörő változás; ha meglévő alkalmazást frissít, olvassa el figyelmesen az alábbiakat.

Kompatibilitástörő változás hatás
A diszkriminatív tulajdonság neve mostantól $type helyett Discriminator Magas
A id tulajdonság alapértelmezés szerint már nem tartalmazza a diszkriminátort Magas
A JSON id tulajdonság a kulcshoz van leképezve Magas
A szinkron I/O az Azure Cosmos DB-szolgáltatón keresztül már nem támogatott Közepes
SQL-lekérdezésnek most már közvetlenül JSON-értékeket kell kivetítenie Közepes
A nem definiált eredmények mostantól automatikusan szűrve lesznek a lekérdezési eredményekből Közepes
A helytelenül lefordított lekérdezések már nem lesznek lefordítva Közepes
HasIndex mostantól hibát jelez, ahelyett hogy figyelmen kívül hagynák Alacsony
9.0.0-rc.2 után a átnevezték -re Alacsony

Nagy hatású változások

A diszkriminatív tulajdonság neve mostantól $typeDiscriminator helyett

nyomon követési probléma #34269

Régi viselkedés

Az EF automatikusan hozzáad egy megkülönböztető tulajdonságot a JSON-dokumentumokhoz a dokumentum által képviselt entitástípus azonosításához. Az EF korábbi verzióiban ez a JSON-tulajdonság alapértelmezés szerint Discriminator volt elnevezve.

Új viselkedés

Az EF Core 9.0-tól kezdve a diszkriminatív tulajdonság mostantól alapértelmezés szerint $type. Ha az EF korábbi verzióiból származó meglévő dokumentumokkal rendelkezik az Azure Cosmos DB-ben, ezek a régi Discriminator elnevezést használják, és az EF 9.0-ra való frissítés után a dokumentumokra vonatkozó lekérdezések sikertelenek lesznek.

Miért

Egy újonnan megjelenő JSON-gyakorlat egy $type tulajdonságot használ olyan helyzetekben, ahol a dokumentum típusát azonosítani kell. Például a .NET System.Text.Json szintén támogatja a polimorfizmust, és a $type-t használja alapértelmezett diszkriminátor tulajdonságnévként (dokumentumok). Az ökoszisztéma többi részéhez való igazodás és a külső eszközökkel való együttműködés megkönnyítése érdekében az alapértelmezett beállítás módosult.

Enyhítések

A legegyszerűbb megoldás, ha egyszerűen konfigurálja a megkülönböztető tulajdonság nevét Discriminator, ugyanúgy, mint korábban:

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

Ha ezt az összes legfelső szintű entitástípus esetében végzi, az EF ugyanúgy fog viselkedni, mint korábban.

Ezen a ponton, ha szeretné, frissítheti az összes dokumentumot az új $type elnevezés használatára.

A id tulajdonság alapértelmezés szerint csak az EF-kulcs tulajdonságot tartalmazza

nyomon követési probléma #34179

Régi viselkedés

Korábban az EF beszúrta az entitástípus diszkriminatív értékét a dokumentum id tulajdonságába. Ha például elmentett egy Blog entitástípust, amely 8-at tartalmazó Id tulajdonsággal rendelkezik, akkor a JSON id tulajdonság Blog|8tartalmazna.

Új viselkedés

Az EF Core 9.0-tól kezdve a JSON id tulajdonság már nem tartalmazza a diszkriminatív értéket, és csak a kulcstulajdonság értékét tartalmazza. A fenti példában a JSON id tulajdonság egyszerűen 8. Ha az EF korábbi verzióiból származó meglévő dokumentumokkal rendelkezik az Azure Cosmos DB-ben, ezek a JSON id tulajdonság diszkriminatív értékkel rendelkeznek, és az EF 9.0-ra való frissítés után a dokumentumokra vonatkozó lekérdezések sikertelenek lesznek.

Miért

Mivel a JSON id tulajdonságnak egyedinek kell lennie, a diszkriminatív tulajdonságot korábban hozzáadták hozzá, hogy különböző, azonos kulcsértékkel rendelkező entitások létezhessenek. Ez lehetővé tette például, hogy egy Blog és egy Post is rendelkezik egy Id tulajdonsággal, amely a 8 értéket tartalmazza ugyanabban a tárolóban és partícióban. Ez jobban megfelelt a relációs adatbázis adatmodellezési mintáinak, ahol minden entitástípus a saját táblájára van leképezve, és így saját kulcstérrel rendelkezik.

Az EF 9.0 általában úgy módosította a leképezést, hogy jobban igazodjon a gyakori Azure Cosmos DB NoSQL-eljárásokhoz és elvárásokhoz, ahelyett, hogy megfelelteti a relációs adatbázisokból érkező felhasználók elvárásait. Ezenkívül az id tulajdonság diszkriminatív értékével megnehezítette a külső eszközök és rendszerek számára az EF által létrehozott JSON-dokumentumokkal való interakciót; az ilyen külső rendszerek általában nem ismerik az EF diszkriminatív értékeit, amelyek alapértelmezés szerint .NET-típusokból származnak.

Enyhítések

Mint korábban, a legegyszerűbb megoldás az, ha egyszerűen úgy konfigurálja az Entity Framework-öt, hogy a diszkriminátor szerepeljen a JSON id tulajdonságban. Erre a célra új konfigurációs lehetőséget vezetünk be:

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

Ha ezt az összes legfelső szintű entitástípus esetében végzi, az EF ugyanúgy fog viselkedni, mint korábban.

Ezen a ponton, ha szeretné, frissítheti az összes dokumentumot is, hogy újraírja a JSON id tulajdonságát. Vegye figyelembe, hogy ez csak akkor lehetséges, ha a különböző típusú entitások nem ugyanazt az azonosítóértéket használják ugyanazon a tárolón belül.

A JSON id tulajdonság a kulcshoz van rendelve

nyomon követési probléma #34179

Régi viselkedés

Korábban az EF létrehozott egy árnyéktulajdonságot, amely a JSON id tulajdonságra volt leképezve, kivéve, ha az egyik tulajdonságot explicit módon a id-re leképezték.

Új viselkedés

Az EF Core 9-től kezdve a kulcstulajdonság a JSON id tulajdonságra lesz leképezve az alapértelmezett eljárás szerint, ha lehetséges. Ez azt jelenti, hogy a kulcstulajdonság már nem marad meg a dokumentumban egy másik néven, ugyanazzal az értékkel, így a dokumentumokat használó és a tulajdonságra támaszkodó nem EF-kód már nem fog megfelelően működni.

Miért

Az EF 9.0 általában úgy módosította a leképezést, hogy jobban igazodjon a gyakori Azure Cosmos DB NoSQL-eljárásokhoz és elvárásokhoz. És nem gyakori, hogy a kulcs értékét kétszer tárolja a dokumentumban.

Enyhítések

Ha meg szeretné őrizni az EF Core 8 viselkedését, a legegyszerűbb megoldás egy új konfigurációs lehetőség használata, amely erre a célra lett bevezetve:

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

Ha ezt az összes legfelső szintű entitástípus esetében végzi, az EF ugyanúgy fog viselkedni, mint korábban. Vagy alkalmazhatja a modell összes entitástípusára egy hívással:

modelBuilder.HasShadowIds();

Közepes hatású változások

Az I/O szinkronizálása az Azure Cosmos DB-szolgáltatón keresztül már nem támogatott

nyomon követési probléma #32563

Régi viselkedés

Korábban, amikor olyan szinkron metódusokat hívtak meg, mint a ToList vagy a SaveChanges, az EF Core szinkron módon blokkolta az aszinkron hívásokat a .GetAwaiter().GetResult() használatával az Azure Cosmos DB SDK ellen. Ez holtpontot eredményezhet.

Új viselkedés

Az EF Core 9.0-tól kezdve az EF alapértelmezés szerint dob, amikor szinkron I/O-t próbál használni. A kivétel üzenete: "Az Azure Cosmos DB nem támogatja a szinkron I/O-t. Győződjön meg arról, hogy csak az aszinkron metódusokat használja és várja meg helyesen, amikor az Entity Framework Core használatával éri el az Azure Cosmos DB-t. További információért tekintse meg a https://aka.ms/ef-cosmos-nosync."

Miért

Az aszinkron metódusok szinkron blokkolása holtpontot eredményezhet, és az Azure Cosmos DB SDK csak az aszinkron metódusokat támogatja.

Enyhítések

Az EF Core 9.0-ban a hiba a következőkkel mellőzhető:

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

Ennek ellenére az alkalmazásoknak abba kell hagyniuk a szinkronizálási API-k használatát az Azure Cosmos DB-vel, mivel ezt az Azure Cosmos DB SDK nem támogatja. A kivétel letiltásának lehetősége az EF Core egy későbbi kiadásában megszűnik, amely után az egyetlen lehetőség az aszinkron API-k használata lesz.

Az SQL-lekérdezéseknek most már közvetlenül JSON-értékeket kell kivetíteniük

Hibakövetési feladat #25527

Régi viselkedés

Korábban az EF létrehozott olyan lekérdezéseket, mint a következők:

SELECT c["City"] FROM root c

Az ilyen lekérdezések miatt az Azure Cosmos DB az egyes eredményeket egy JSON-objektumba csomagolja, az alábbiak szerint:

[
    {
        "City": "Berlin"
    },
    {
        "City": "México D.F."
    }
]
Új viselkedés

Az EF Core 9.0-tól kezdve az EF mostantól hozzáadja a VALUE módosítóját a lekérdezésekhez az alábbiak szerint:

SELECT VALUE c["City"] FROM root c

Az ilyen lekérdezések miatt az Azure Cosmos DB közvetlenül, burkolt becsomagolás nélkül adja vissza az értékeket:

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

Ha az alkalmazás SQL-lekérdezéseket használ, az ef 9.0-ra való frissítés után az ilyen lekérdezések valószínűleg megszakadnak, mivel nem tartalmazzák a VALUE módosítóját.

Miért

Az egyes eredmények egy további JSON-objektumba való körbefuttatása bizonyos esetekben teljesítménycsökkenést okozhat, a JSON-eredmény hasznos adattartalmat felbomíthatja, és nem ez a természetes módja az Azure Cosmos DB-vel való együttműködésnek.

Enyhítések

A mérsékléshez egyszerűen adja hozzá a VALUE módosítót az SQL-lekérdezések előrejelzéseihez, a fent látható módon.

A nem definiált eredmények mostantól automatikusan szűrve lesznek a lekérdezési eredményekből

Hibakövetési feladat #25527

Régi viselkedés

Korábban az EF létrehozott olyan lekérdezéseket, mint a következők:

SELECT c["City"] FROM root c

Az ilyen lekérdezések miatt az Azure Cosmos DB az egyes eredményeket egy JSON-objektumba csomagolja, az alábbiak szerint:

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

Ha az eredmények bármelyike nincs meghatározva (például a City tulajdonság hiányzik a dokumentumból), a rendszer üres dokumentumot ad vissza, és az EF az eredményhez null ad vissza.

Új viselkedés

Az EF Core 9.0-tól kezdve az EF mostantól hozzáadja a VALUE módosítóját a lekérdezésekhez az alábbiak szerint:

SELECT VALUE c["City"] FROM root c

Az ilyen lekérdezések miatt az Azure Cosmos DB közvetlenül, burkolt becsomagolás nélkül adja vissza az értékeket:

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

Az Azure Cosmos DB viselkedése undefined értékek automatikus szűrése az eredményekből; Ez azt jelenti, hogy ha az egyik City tulajdonság hiányzik a dokumentumból, a lekérdezés csak egyetlen eredményt ad vissza két találat helyett, és az egyiket null.

Miért

Az egyes eredmények egy további JSON-objektumba való körbefuttatása bizonyos esetekben teljesítménycsökkenést okozhat, a JSON-eredmény hasznos adattartalmat felbomíthatja, és nem ez a természetes módja az Azure Cosmos DB-vel való együttműködésnek.

Enyhítések

Ha fontos, hogy az alkalmazása null értékeket kapjon a nem definiált eredményekhez, egyesítse a undefined értékeket null-re az új EF.Functions.Coalesce operátorral:

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

A helytelenül lefordított lekérdezések már nem lesznek lefordítva

nyomon követési probléma #34123

Régi viselkedés

Korábban az EF által lefordított lekérdezések, például a következők:

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

A lekérdezés SQL-fordítása azonban helytelen volt:

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

Az SQL-ben a WHERE záradék kiértékelése történik, mielőtt a OFFSET és LIMIT záradékokat; de a fenti LINQ-lekérdezésben a Take operátor megjelenik a Where operátor előtt. Ennek eredményeképpen az ilyen lekérdezések helytelen eredményeket adhatnak vissza.

Új viselkedés

Az EF Core 9.0-tól kezdve az ilyen lekérdezések már nem lesznek lefordítva, és kivétel történik.

Miért

A helytelen fordítások csendes adatsérülést okozhatnak, ami nehezen felderíthető hibákat okozhat az alkalmazásban. Az EF mindig a gyors hibajelzést részesíti előnyben az adatok esetleges sérülésének elkerülése érdekében, hibát jelezve a probléma felmerülésekor.

Enyhítések

Ha elégedett volt az előző viselkedéssel, és ugyanazt az SQL-t szeretné végrehajtani, egyszerűen cserélje le a LINQ-operátorok sorrendjét:

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

Sajnos az Azure Cosmos DB jelenleg nem támogatja az SQL-allekérdezések OFFSET és LIMIT záradékait, ami az eredeti LINQ-lekérdezés megfelelő fordításához szükséges.

Kis hatású módosítások

HasIndex most hibát jelez ahelyett, hogy figyelmen kívül hagyják

nyomon követési probléma #34023

Régi viselkedés

Korábban az EF Cosmos DB-szolgáltató figyelmen kívül hagyta a HasIndex hívásait.

Új viselkedés

A szolgáltató most dob, ha HasIndex van megadva.

Miért

Az Azure Cosmos DB-ben az összes tulajdonság alapértelmezés szerint indexelt, és nincs szükség indexelésre. Bár egyéni indexelési szabályzatot is meghatározhat, ezt az EF jelenleg nem támogatja, és ef-támogatás nélkül is elvégezhető az Azure Portalon. Mivel HasIndex hívások nem tettek semmit, többé nem engedélyezettek.

Enyhítések

Távolítsa el a HasIndexhívásait.

IncludeRootDiscriminatorInJsonId 9.0.0-rc.2 után átnevezték HasRootDiscriminatorInJsonId-re

Követési feladat #34717

Régi viselkedés

A IncludeRootDiscriminatorInJsonId API a 9.0.0 rc.1-ben lett bevezetve.

Új viselkedés

Az EF Core 9.0 végleges kiadásához az API-t átnevezték HasRootDiscriminatorInJsonId

Miért

Egy másik kapcsolódó API-t átneveztek Has-re Includehelyett, így ezt is átnevezték konzisztenciaként.

Enyhítések

Ha a kód a IncludeRootDiscriminatorInJsonId API-t használja, egyszerűen módosítsa úgy, hogy a IncludeRootDiscriminatorInJsonId API helyett a API-ra hivatkozzon.