Kaszkádolt törlés

Az Entity Framework Core (EF Core) az idegen kulcsokat használó kapcsolatokat jelöli. Az idegen kulccsal rendelkező entitás a kapcsolat gyermek vagy függő entitása. Az entitás idegenkulcs-értékének meg kell egyeznie a kapcsolódó fő/szülő entitás elsődleges kulcsértékével (vagy alternatív kulcsértékével).

Ha a rendszer törli a fő/szülő entitást, akkor a függők/gyermekek idegenkulcs-értékei többé nem egyeznek meg a fő/ szülő elsődleges vagy másodlagos kulcsával. Ez érvénytelen állapot, és hivatkozási kényszer megsértését okozza a legtöbb adatbázisban.

A hivatkozási kényszer megsértésének elkerülésére két lehetőség áll rendelkezésre:

1. Az FK értékeinek beállítása null értékre
2. A függő/gyermek entitások törlése is

Az első beállítás csak olyan választható kapcsolatokra érvényes, ahol az idegenkulcs-tulajdonságnak (és az adatbázis oszlopának, amelyhez megfeleltetve van) null értékűnek kell lennie.

A második lehetőség bármilyen kapcsolatra érvényes, és "kaszkádolt törlésnek" is nevezik.

Jótanács

Ez a dokumentum az adatbázis frissítése szempontjából a kaszkádolt törléseket (és az árvák törlését) ismerteti. A változáskövetésben az EF Core-ban , valamint az idegen kulcsok és navigációk módosítása során bevezetett fogalmakat nagyban kihasználja. Az itt található anyag kezelése előtt mindenképpen tisztában kell lenni ezekkel a fogalmakkal.

Jótanács

A mintakód GitHubról való letöltésével futtathatja és hibakeresést végezhet a dokumentum összes kódjában.

Kaszkádolt viselkedések esetén

Kaszkádolt törlésre akkor van szükség, amikor egy függő/gyermek entitás már nem társítható az aktuális főentitással/szülővel. Ez azért fordulhat elő, mert a fő/szülő törölve lett, vagy akkor, ha a fő/szülő még létezik, de a függő/gyermek már nem kapcsolódik hozzá.

Főnév/szülő törlése

Fontolja meg ezt az egyszerű modellt, amelyben Blog a fő/szülő egy kapcsolatban van Post-nel, amely a függő/gyermek. Post.BlogId egy idegenkulcs-tulajdonság, amelynek értéke meg kell egyeznie annak a blognak az Blog.Id elsődleges kulcsával, amelyhez a bejegyzés tartozik.

public class Blog
{
    public int Id { get; set; }

    public string Name { get; set; }

    public IList<Post> Posts { get; } = new List<Post>();
}

public class Post
{
    public int Id { get; set; }

    public string Title { get; set; }
    public string Content { get; set; }

    public int BlogId { get; set; }
    public Blog Blog { get; set; }
}

Konvenció szerint ez a kapcsolat kötelezőként van konfigurálva, mivel az Post.BlogId idegenkulcs-tulajdonság nem null értékű. A szükséges kapcsolatok alapértelmezés szerint kaszkádolt törlés használatára vannak konfigurálva. A kapcsolatok modellezésével kapcsolatos további információkért lásd a Kapcsolatok című témakört.

Blog törlésekor az összes bejegyzés kaszkád módon törlődik. Például:

using var context = new BlogsContext();

var blog = await context.Blogs.OrderBy(e => e.Name).Include(e => e.Posts).FirstAsync();

context.Remove(blog);

await context.SaveChangesAsync();

A SaveChanges a következő SQL-t hozza létre, példaként az SQL Servert használva:

-- Executed DbCommand (1ms) [Parameters=[@p0='1'], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
DELETE FROM [Posts]
WHERE [Id] = @p0;
SELECT @@ROWCOUNT;

-- Executed DbCommand (0ms) [Parameters=[@p0='2'], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
DELETE FROM [Posts]
WHERE [Id] = @p0;
SELECT @@ROWCOUNT;

-- Executed DbCommand (2ms) [Parameters=[@p1='1'], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
DELETE FROM [Blogs]
WHERE [Id] = @p1;
SELECT @@ROWCOUNT;

Kapcsolat megszakítása

Ahelyett, hogy törölnénk a blogot, megszüntethetnénk az egyes bejegyzések és a blog közötti kapcsolatot. Ezt úgy teheti meg, hogy a hivatkozási navigációt Post.Blog null értékre állítja az egyes bejegyzésekhez:

using var context = new BlogsContext();

var blog = await context.Blogs.OrderBy(e => e.Name).Include(e => e.Posts).FirstAsync();

foreach (var post in blog.Posts)
{
    post.Blog = null;
}

await context.SaveChangesAsync();

A kapcsolat megszakadhat úgy is, hogy eltávolítja az egyes bejegyzéseket a Blog.Posts gyűjtemény navigációs sávjából:

using var context = new BlogsContext();

var blog = await context.Blogs.OrderBy(e => e.Name).Include(e => e.Posts).FirstAsync();

blog.Posts.Clear();

await context.SaveChangesAsync();

Mindkét esetben az eredmény ugyanaz: a blog nem törlődik, de a bloghoz már nem társított bejegyzések törlődnek:

-- Executed DbCommand (1ms) [Parameters=[@p0='1'], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
DELETE FROM [Posts]
WHERE [Id] = @p0;
SELECT @@ROWCOUNT;

-- Executed DbCommand (0ms) [Parameters=[@p0='2'], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
DELETE FROM [Posts]
WHERE [Id] = @p0;
SELECT @@ROWCOUNT;

Az olyan entitások törlése, amelyek már nem tartoznak egyetlen taghoz vagy függőhöz sem, az úgynevezett "árvák törlése".

Jótanács

A kaszkádtörlés és az árvák törlése szorosan összefügg. Mindkettő a függő/gyermek entitások törlését eredményezi, ha az adott esetben szükséges főentitáshoz/szülőhöz való kapcsolat megszakad. Kaszkádolt törlés esetén ez a leválasztás azért történik, mert maga a fő/szülő van törölve. Árvák esetén a fő/szülő entitás továbbra is létezik, de már nem kapcsolódik a függő/gyermek entitásokhoz.

Ahol kaszkádolt viselkedések történnek

A kaszkádolt viselkedések a következőre alkalmazhatók:

• Az aktuális DbContext által nyomon követett entitások
• Az adatbázis azon entitásai, amelyek nincsenek betöltve a munkakörnyezetbe

Nyomon követett entitások kaszkádolt törlése

Az EF Core mindig konfigurált kaszkádolt viselkedéseket alkalmaz a nyomon követett entitásokra. Ez azt jelenti, hogy ha az alkalmazás betölti az összes releváns függő/gyermek entitást a DbContextbe, ahogyan a fenti példákban is látható, akkor a kaszkádolt viselkedések megfelelően lesznek alkalmazva az adatbázis konfigurálásának módjától függetlenül.

Jótanács

A nyomon követett entitások kaszkádolt viselkedésének pontos időzítése szabályozható ChangeTracker.CascadeDeleteTiming az és ChangeTracker.DeleteOrphansTiminga használatával. További információt az Idegen kulcsok és navigációk módosítása című témakörben talál.

Kaszkádos törlés az adatbázisban

Számos adatbázisrendszer kaszkádolt viselkedést is kínál, amelyek akkor aktiválódnak, amikor egy entitást törölnek az adatbázisban. Az EF Core ezeket a viselkedéseket az EF Core-modell kaszkádolt törlési viselkedése alapján konfigurálja, amikor adatbázist hoz létre az EF Core-migrálás vagy az EF Core-áttelepítések használatával EnsureCreated . A fenti modell használatával például a következő táblázat jön létre a bejegyzésekhez az SQL Server használatakor:

CREATE TABLE [Posts] (
    [Id] int NOT NULL IDENTITY,
    [Title] nvarchar(max) NULL,
    [Content] nvarchar(max) NULL,
    [BlogId] int NOT NULL,
    CONSTRAINT [PK_Posts] PRIMARY KEY ([Id]),
    CONSTRAINT [FK_Posts_Blogs_BlogId] FOREIGN KEY ([BlogId]) REFERENCES [Blogs] ([Id]) ON DELETE CASCADE
);

Figyelje meg, hogy a blogok és bejegyzések közötti kapcsolatot meghatározó idegenkulcs-korlátozás a következővel ON DELETE CASCADEvan konfigurálva: .

Ha tudjuk, hogy az adatbázis így van konfigurálva, akkor törölhetünk egy blogot anélkül, hogy először betöltenénk a bejegyzéseket , és az adatbázis gondoskodik a bloghoz kapcsolódó összes bejegyzés törléséről. Például:

using var context = new BlogsContext();

var blog = await context.Blogs.OrderBy(e => e.Name).FirstAsync();

context.Remove(blog);

await context.SaveChangesAsync();

Figyelje meg, hogy a bejegyzésekhez nincs Include címke, így azok nincsenek betöltve. A SaveChanges ebben az esetben csak a blogot törli, mivel ez az egyetlen nyomon követett entitás:

-- Executed DbCommand (6ms) [Parameters=[@p0='1'], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
DELETE FROM [Blogs]
WHERE [Id] = @p0;
SELECT @@ROWCOUNT;

Ez kivételt eredményezne, ha az adatbázisban lévő idegenkulcs-korlátozás nincs konfigurálva kaszkádolt törlésekhez. Azonban ebben az esetben az adatbázis törli a bejegyzéseket, mert a létrehozáskor ON DELETE CASCADE-vel lett beállítva.

Megjegyzés:

Az adatbázisokban általában nincs automatikus módszer az árva rekordok törlésére. Ennek az az oka, hogy míg az EF Core a navigációs és az idegen kulcsokat használó kapcsolatokat jelöli, az adatbázisok csak idegen kulcsokkal rendelkeznek, és nincsenek navigációk. Ez azt jelenti, hogy általában nem lehet megszakítani egy kapcsolatot anélkül, hogy mindkét oldalt betöltenek a DbContextbe.

Megjegyzés:

Az EF Core memórián belüli adatbázisa jelenleg nem támogatja a kaszkádolt törléseket az adatbázisban.

Figyelmeztetés

Ne konfigurálja a kaszkádolt törlést az adatbázisban az entitások szoftveres törlésekor. Ez azt eredményezheti, hogy az entitások véletlenül véglegesen törlődnek ahelyett, hogy csak ideiglenesen lennének törölve.

Az adatbázis kaszkád korlátozásai

Egyes adatbázisok, különösen az SQL Server, korlátozásokkal rendelkeznek a ciklusokat alkotó kaszkádolt viselkedésekre. Vegyük például a következő modellt:

public class Blog
{
    public int Id { get; set; }
    public string Name { get; set; }

    public IList<Post> Posts { get; } = new List<Post>();

    public int OwnerId { get; set; }
    public Person Owner { get; set; }
}

public class Post
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }

    public int BlogId { get; set; }
    public Blog Blog { get; set; }

    public int AuthorId { get; set; }
    public Person Author { get; set; }
}

public class Person
{
    public int Id { get; set; }
    public string Name { get; set; }

    public IList<Post> Posts { get; } = new List<Post>();

    public Blog OwnedBlog { get; set; }
}

Ez a modell három kapcsolattal rendelkezik, mindegyik szükséges, ezért konvenciók szerint kaszkádolt törlésre van konfigurálva:

• A blog törlése kaszkádoltan törli az összes kapcsolódó bejegyzést
• A bejegyzések szerzőjének törlése a bejegyzések automatikus törlését okozza.
• A blog tulajdonosának törlése a blog kaszkádolt törlését eredményezi

Ez ésszerűnek tűnik (még ha kissé drákóinak is a blogkezelési szabályok szempontjából!), de ezeknek a kaszkádoknak a konfigurálásával egy SQL Server-adatbázis létrehozása a következő kivételt eredményezi:

Microsoft.Data.SqlClient.SqlException (0x80131904): A "Post" táblában a "FK_Posts_Person_AuthorId" IDEGENKULCS-kényszer bevezetése ciklusokat vagy több kaszkádolt útvonalat okozhat. Adja meg a "TÖRLÉSKOR NINCS MŰVELET" vagy a "FRISSÍTÉSKOR NINCS MŰVELET" lehetőséget, vagy módosítsa az egyéb IDEGEN KULCS korlátozásokat.

Ezt a helyzetet kétféleképpen lehet kezelni.

1. Módosítsa egy vagy több kapcsolatát úgy, hogy ne legyen kaszkádolt törlés.
2. Konfigurálja az adatbázist egy vagy több kaszkádolt törlés nélkül, majd győződjön meg arról, hogy az összes függő entitás betöltődik, hogy az EF Core végrehajthassa a kaszkádolt viselkedést.

A példánk első megközelítését figyelembe véve a blog utáni kapcsolatot opcionálissá tehetjük úgy, hogy null értékű idegenkulcs-tulajdonságot adunk neki:

public int? BlogId { get; set; }

Az opcionális kapcsolat lehetővé teszi, hogy a bejegyzés blog nélkül létezhessen, ami azt jelenti, hogy a kaszkádolt törlés alapértelmezés szerint nem lesz konfigurálva. Ez azt jelenti, hogy már nincs ciklus a kaszkádolt műveletekben, és az adatbázis hiba nélkül hozható létre az SQL Serveren.

A második megközelítés helyett megtarthatjuk a blogtulajdonosi kapcsolatot, és konfigurálhatjuk a kaszkádolt törléshez, de ezt a konfigurációt csak a nyomon követett entitásokra, nem pedig az adatbázisra alkalmazhatjuk:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .Entity<Blog>()
        .HasOne(e => e.Owner)
        .WithOne(e => e.OwnedBlog)
        .OnDelete(DeleteBehavior.ClientCascade);
}

Mi történik most, ha betöltünk egy személyt és a birtokában lévő blogot is, majd töröljük a személyt?

using var context = new BlogsContext();

var owner = await context.People.SingleAsync(e => e.Name == "ajcvickers");
var blog = await context.Blogs.SingleAsync(e => e.Owner == owner);

context.Remove(owner);

await context.SaveChangesAsync();

Az EF Core végrehajtja a tulajdonos kaszkádos törlését, ezért a blog is törlődik.

-- Executed DbCommand (8ms) [Parameters=[@p0='1'], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
DELETE FROM [Blogs]
WHERE [Id] = @p0;
SELECT @@ROWCOUNT;

-- Executed DbCommand (2ms) [Parameters=[@p1='1'], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
DELETE FROM [People]
WHERE [Id] = @p1;
SELECT @@ROWCOUNT;

Ha azonban a blog nincs betöltve a tulajdonos törlésekor:

using var context = new BlogsContext();

var owner = await context.People.SingleAsync(e => e.Name == "ajcvickers");

context.Remove(owner);

await context.SaveChangesAsync();

A rendszer kivételt fog kivenni az adatbázis idegenkulcs-korlátozásának megsértése miatt:

Microsoft.Data.SqlClient.SqlException: A DELETE utasítás ütközött a "FK_Blogs_People_OwnerId" hivatkozási kényszersel. Az konfliktus az "Scratch" adatbázis "dbo.Blogs" táblájában, az 'OwnerId' oszlopban történt. Az utasítás megszakadt.

Kaszkádolt nullértékek

A választható kapcsolatok null értékű külső kulcstulajdonságokkal rendelkeznek, amelyek null értékű adatbázisoszlopokra vannak leképezve. Ez azt jelenti, hogy az idegen kulcs értéke null értékű lehet, ha az aktuális fő/szülő törlődik, vagy a függőtől/gyermektől lesz elválasztva.

Tekintsük meg újra a példákat a When cascading behaviors happen című részben, de ezúttal egy null értékűvé tehető Post.BlogId idegenkulcs-tulajdonság által képviselt opcionális kapcsolattal:

public int? BlogId { get; set; }

Ez az idegenkulcs-tulajdonság minden bejegyzéshez null értékű lesz, amikor a kapcsolódó blogot törlik. Ez a kód például ugyanaz, mint korábban:

using var context = new BlogsContext();

var blog = await context.Blogs.OrderBy(e => e.Name).Include(e => e.Posts).FirstAsync();

context.Remove(blog);

await context.SaveChangesAsync();

A SaveChanges meghívásakor a következő adatbázis-frissítések jelennek meg:

-- Executed DbCommand (2ms) [Parameters=[@p1='1', @p0=NULL (DbType = Int32)], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
UPDATE [Posts] SET [BlogId] = @p0
WHERE [Id] = @p1;
SELECT @@ROWCOUNT;

-- Executed DbCommand (0ms) [Parameters=[@p1='2', @p0=NULL (DbType = Int32)], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
UPDATE [Posts] SET [BlogId] = @p0
WHERE [Id] = @p1;
SELECT @@ROWCOUNT;

-- Executed DbCommand (1ms) [Parameters=[@p2='1'], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
DELETE FROM [Blogs]
WHERE [Id] = @p2;
SELECT @@ROWCOUNT;

Hasonlóképpen, ha a kapcsolat megszakad a fenti példák valamelyikével:

using var context = new BlogsContext();

var blog = await context.Blogs.OrderBy(e => e.Name).Include(e => e.Posts).FirstAsync();

foreach (var post in blog.Posts)
{
    post.Blog = null;
}

await context.SaveChangesAsync();

Vagy:

using var context = new BlogsContext();

var blog = await context.Blogs.OrderBy(e => e.Name).Include(e => e.Posts).FirstAsync();

blog.Posts.Clear();

await context.SaveChangesAsync();

Ezután a rendszer null értékű külső kulcsértékekkel frissíti a bejegyzéseket a SaveChanges meghívásakor:

-- Executed DbCommand (2ms) [Parameters=[@p1='1', @p0=NULL (DbType = Int32)], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
UPDATE [Posts] SET [BlogId] = @p0
WHERE [Id] = @p1;
SELECT @@ROWCOUNT;

-- Executed DbCommand (0ms) [Parameters=[@p1='2', @p0=NULL (DbType = Int32)], CommandType='Text', CommandTimeout='30']
SET NOCOUNT ON;
UPDATE [Posts] SET [BlogId] = @p0
WHERE [Id] = @p1;
SELECT @@ROWCOUNT;

Az idegen kulcsok és navigációk módosítása című témakörben további információt talál arról, hogy az EF Core hogyan kezeli az idegen kulcsokat és navigációkat az értékük módosításakor.

Megjegyzés:

Az ilyen kapcsolatok javítása az Entity Framework alapértelmezett viselkedése a 2008-as első verzió óta. Az EF Core előtt nem volt neve, és nem lehetett módosítani. Most már ClientSetNull néven ismert, ahogyan azt a következő szakasz leírja.

Az adatbázisok úgy is konfigurálhatók, hogy null értékeket kaszkádozzanak, amikor törlik a fő/szülő elemet egy opcionális kapcsolatban. Ez azonban sokkal kevésbé gyakori, mint a kaszkádolt törlések használata az adatbázisban. Ha egyidejűleg kaszkádolt törléseket és kaszkádolt null értékeket használ az adatbázisban, az SQL Server használatakor szinte mindig kapcsolati ciklusokat eredményez. A kaszkádolt nullértékek konfigurálásáról a következő szakaszban talál további információt.

Kaszkádolt viselkedés konfigurálása

Jótanács

Mindenképpen olvassa el a fenti szakaszokat, mielőtt idejön. A konfigurációs opciók valószínűleg nem fognak értelmet nyerni, ha az előző anyag nem érthető.

Kaszkádolt viselkedések kapcsolatonként konfigurálhatók a OnDelete metódusban OnModelCreating. Például:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .Entity<Blog>()
        .HasOne(e => e.Owner)
        .WithOne(e => e.OwnedBlog)
        .OnDelete(DeleteBehavior.ClientCascade);
}

Az entitástípusok közötti kapcsolatok konfigurálásáról további információt a Kapcsolatok című témakörben talál.

OnDelete elfogad egy értéket az elismerhetően zavaros DeleteBehavior enumerálásból. Ez az enumerálás meghatározza az EF Core viselkedését a nyomon követett entitásokon, valamint a kaszkádolt törlés konfigurálását az adatbázisban, amikor az EF-t a séma létrehozásához használják.

Az adatbázissémára gyakorolt hatás

Az alábbi táblázat az egyes OnDelete értékek eredményét mutatja, amikor az EF Core migrációk vagy a EnsureCreated által létrehozott külföldi kulcs megszorításra alkalmazzák.

DeleteBehavior	Az adatbázissémára gyakorolt hatás
Vízesés	TÖRLÉS ELŐRENDÉLÉSESEN (CASCADE)
Korlátoz	TÖRLÉS KORLÁTOZÁSAKOR
NincsAkció	alapértelmezett adatbázis
SetNull	"TÖRLÉSNÉL NULLA ÉRTÉK BEÁLLÍTÁSA"
ClientSetNull	alapértelmezett adatbázis
ClientCascade	alapértelmezett adatbázis
ClientNoAction	alapértelmezett adatbázis

Az ON DELETE NO ACTION (az adatbázis alapértelmezett értéke) és ON DELETE RESTRICT viselkedése a relációs adatbázisokban általában azonos vagy nagyon hasonló. Annak ellenére, hogy mi NO ACTION jelentheti ezt, mindkét lehetőség hivatkozási korlátozásokat kényszerít. A különbség, ha van ilyen, az az, amikor az adatbázis ellenőrzi a korlátozásokat. Ellenőrizze az adatbázis dokumentációját, hogy milyen különbségek vannak ON DELETE NO ACTION és ON DELETE RESTRICT között az adatbázis rendszerében.

Az SQL Server nem támogatja ON DELETE RESTRICT, ezért ON DELETE NO ACTION inkább használják.

Az egyetlen érték, amely kaszkádolt viselkedést okoz az adatbázisban, az Cascade és SetNulla . Az összes többi érték úgy konfigurálja az adatbázist, hogy ne kaszkádolt legyen a módosítások.

A SaveChanges viselkedésének hatása

A következő szakaszok táblázatai azt ismertetik, hogy mi történik a függő/gyermek entitásokkal a fő/szülő törlésekor vagy a függő/gyermek entitásokhoz való viszonyának megszakadásakor. Minden táblázat az alábbiak egyikét fedi le:

• Nem kötelező (null értékű FK) és kötelező (nem null értékű FK) kapcsolatok
• Ha a dbContext betölti és nyomon követi az eltartottakat/gyermekeket, és csak az adatbázisban vannak

Szükséges kapcsolat a eltartottakkal/betöltött gyermekekkel

DeleteBehavior	A főnév/szülő törlésekor	A főnévtől/szülőtől való leváláskor
Vízesés	Az EF Core által törölt függők	Az EF Core által törölt függők
Korlátoz	InvalidOperationException	InvalidOperationException
NincsAkció	InvalidOperationException	InvalidOperationException
SetNull	SqlException az adatbázis létrehozásáról	SqlException az adatbázis létrehozásáról
ClientSetNull	InvalidOperationException	InvalidOperationException
ClientCascade	Az EF Core által törölt függők	Az EF Core által törölt függők
ClientNoAction	DbUpdateException	InvalidOperationException

Megjegyzések:

• Az ehhez hasonló kötelező kapcsolatok alapértelmezett értéke.Cascade
• Ha a kötelező kapcsolatok esetében nem kaszkádtörlést használ, akkor kivétel keletkezik, amikor a SaveChanges meghívásra kerül.
  • Ez általában az InvalidOperationException EF Core-tól származik, mivel a rendszer az érvénytelen állapotot észleli a betöltött gyermekekben/eltartottakban.
  • ClientNoAction Kényszeríti az EF Core-t, hogy ne ellenőrizze a javítás függő objektumait, mielőtt elküldené őket az adatbázisba, így ebben az esetben az adatbázis kivételt vet fel, amelyet aztán a SaveChanges DbUpdateException becsomagol.
  • SetNull az adatbázis létrehozásakor a rendszer elutasítja, mivel az idegenkulcs-oszlop nem null értékű.
• Mivel a függők/gyermekek betöltve vannak, az EF Core mindig törli őket, és soha nem hagyják el az adatbázis törlését.

Szükséges kapcsolat a függőkkel/gyermekekkel nem lett betöltve

DeleteBehavior	A főnév/szülő törlésekor	A főnévtől/szülőtől való leváláskor
Vízesés	Az adatbázis által törölt függők	Nincs adat.
Korlátoz	DbUpdateException	Nincs adat.
NincsAkció	DbUpdateException	Nincs adat.
SetNull	SqlException az adatbázis létrehozásáról	Nincs adat.
ClientSetNull	DbUpdateException	Nincs adat.
ClientCascade	DbUpdateException	Nincs adat.
ClientNoAction	DbUpdateException	Nincs adat.

Megjegyzések:

• A kapcsolat megszakítása itt nem érvényes, mivel a függők/gyermekek nincsenek betöltve.
• Az ehhez hasonló kötelező kapcsolatok alapértelmezett értéke.Cascade
• Ha a kötelező kapcsolatok esetében nem kaszkádtörlést használ, akkor kivétel keletkezik, amikor a SaveChanges meghívásra kerül.
  • Ez általában azért van DbUpdateException, mert a függők/gyermekek nincsenek betöltve, így az érvénytelen állapotot csak az adatbázis képes észlelni. SaveChanges ezután az adatbázis-kivételt egy DbUpdateException-be csomagolja.
  • SetNull az adatbázis létrehozásakor a rendszer elutasítja, mivel az idegenkulcs-oszlop nem null értékű.

Nem kötelező kapcsolat az eltartottakkal/gyerekekkel

DeleteBehavior	A főnév/szülő törlésekor	A főnévtől/szülőtől való leváláskor
Vízesés	Az EF Core által törölt függők	Az EF Core által törölt függők
Korlátoz	Az EF Core által null értékre beállított függő FK-k	Az EF Core által null értékre beállított függő FK-k
NincsAkció	Az EF Core által null értékre beállított függő FK-k	Az EF Core által null értékre beállított függő FK-k
SetNull	Az EF Core által null értékre beállított függő FK-k	Az EF Core által null értékre beállított függő FK-k
ClientSetNull	Az EF Core által null értékre beállított függő FK-k	Az EF Core által null értékre beállított függő FK-k
ClientCascade	Az EF Core által törölt függők	Az EF Core által törölt függők
ClientNoAction	DbUpdateException	Az EF Core által null értékre beállított függő FK-k

Megjegyzések:

• Az ilyen választható kapcsolatok alapértelmezett értéke a következő ClientSetNull.
• A függők/gyermekek soha nem törlődnek, kivéve, ha CascadeClientCascade konfigurálva vannak.
• Minden más érték miatt a függő FK-k null értékre vannak állítva az EF Core által...
  • ... kivéve ClientNoAction , amely arra utasítja az EF Core-t, hogy ne érintse meg az eltartottak/gyermekek idegen kulcsait a fő/szülő törlésekor. Az adatbázis ezért kivételt dob, amelyet a SaveChanges DbUpdateException formájában becsomagol.

Nem kötelező, nem betöltött kapcsolat függőkkel/gyermekekkel

DeleteBehavior	A főnév/szülő törlésekor	A főnévtől/szülőtől való leváláskor
Vízesés	Az adatbázis által törölt függők	Nincs adat.
Korlátoz	DbUpdateException	Nincs adat.
NincsAkció	DbUpdateException	Nincs adat.
SetNull	A függő FK-k adatbázisonként null értékre van állítva	Nincs adat.
ClientSetNull	DbUpdateException	Nincs adat.
ClientCascade	DbUpdateException	Nincs adat.
ClientNoAction	DbUpdateException	Nincs adat.

Megjegyzések:

• A kapcsolat megszakítása itt nem érvényes, mivel a függők/gyermekek nincsenek betöltve.
• Az ilyen választható kapcsolatok alapértelmezett értéke a következő ClientSetNull.
• A függőket/gyermekeket be kell tölteni az adatbázis kivételének elkerülése érdekében, kivéve, ha az adatbázist úgy konfigurálták, hogy a törléseket vagy null értékeket kaszkádolják.