Kaskadborttagning

Entity Framework Core (EF Core) representerar relationer med hjälp av främmande nycklar. En entitet med en främmande nyckel är den underordnade eller beroende entiteten i förhållandet. Den här entitetens främmande nyckelvärde måste matcha det primära nyckelvärdet (eller ett alternativt nyckelvärde) för den relaterade huvudentiteten/den överordnade enheten.

Om den primära/överordnade entiteten tas bort kommer sekundärnyckelvärden för de beroende/underordnade enheterna inte längre att matcha den primära eller alternativa nyckeln för någon primär/överordnad. Detta är ett ogiltigt tillstånd och orsakar en referensbegränsningsöverträdelse i de flesta databaser.

Det finns två alternativ för att undvika den här referensbegränsningsöverträdelsen:

1. Ange FK-värdena till null
2. Ta också bort beroende/underordnade entiteter

Det första alternativet är endast giltigt för valfria relationer där egenskapen sekundärnyckel (och databaskolumnen som den mappas till) måste vara null.

Det andra alternativet är giltigt för alla typer av relationer och kallas "kaskadborttagning".

När sammanhängande beteenden inträffar

Cascaderande borttagningar krävs när en beroende-/underordnad entitet inte längre kan associeras med dess aktuella huvudentitet/överordnade. Detta kan inträffa eftersom huvudobjektet tas bort, eller när huvudobjektet fortfarande finns men beroendeobjektet inte längre är associerat med det.

Ta bort en huvudansvarig/förälder

Tänk dig den här enkla modellen där Blog är huvudman/förälder i en relation med Post, som är beroende/barn. Post.BlogId är en sekundärnyckelegenskap, vars värde måste matcha den Blog.Id primära nyckeln i den blogg som inlägget tillhör.

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; }
}

Enligt konventionen är den här relationen konfigurerad som obligatorisk, eftersom egenskapen Post.BlogId främmande nyckel inte är nullbar. Nödvändiga relationer är konfigurerade för att använda kaskadborttagningar som standard. Mer information om modelleringsrelationer finns i Relationer .

När du tar bort en blogg, raderas alla inlägg i en kaskad. Till exempel:

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();

SaveChanges genererar följande SQL med SQL Server som exempel:

-- 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;

Avsluta en relation

I stället för att ta bort bloggen kan vi i stället bryta relationen mellan varje inlägg och dess blogg. Detta kan göras genom att ange referensnavigeringen Post.Blog till null för varje inlägg:

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();

Relationen kan också avhuggas genom att ta bort varje inlägg från samlingsnavigering Blog.Posts :

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();

I båda fallen är resultatet detsamma: bloggen tas inte bort, men de inlägg som inte längre är associerade med någon blogg tas bort:

-- 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;

Att radera entiteter som inte längre är associerade med någon huvud-/beroendeentitet kallas "radera överblivna".

Där sammanhängande beteenden inträffar

Sammanhängande beteenden kan tillämpas på:

• Entiteter som spåras av den nuvarande DbContext
• Entiteter i databasen som inte har lästs in i kontexten

Kaskadborttagning av spårade entiteter

EF Core tillämpar alltid konfigurerade sammanhängande beteenden för spårade entiteter. Det innebär att om programmet läser in alla relevanta beroende/underordnade entiteter i DbContext, som visas i exemplen ovan, tillämpas sammanhängande beteenden korrekt oavsett hur databasen har konfigurerats.

Kaskadborttagning i databasen

Många databassystem erbjuder också sammanhängande beteenden som utlöses när en entitet tas bort i databasen. EF Core konfigurerar dessa beteenden baserat på beteendet för kaskadborttagning i EF Core-modellen när en databas skapas med hjälp av EnsureCreated eller EF Core-migreringar. Med hjälp av modellen ovan skapas till exempel följande tabell för inlägg när du använder SQL Server:

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
);

Lägg märke till att den främmande nyckelkonstrainten som definierar relationen mellan bloggar och inlägg har konfigurerats med ON DELETE CASCADE.

Om vi vet att databasen är konfigurerad så här kan vi ta bort en blogg utan att först läsa in inlägg och databasen tar hand om att ta bort alla inlägg som var relaterade till den bloggen. Till exempel:

using var context = new BlogsContext();

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

context.Remove(blog);

await context.SaveChangesAsync();

Observera att det inte finns något Include för inlägg, så de läses inte in. SaveChanges i det här fallet tar bort bara bloggen, eftersom det är den enda entiteten som spåras:

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

Detta skulle resultera i ett undantag om begränsningen för sekundärnyckeln i databasen inte har konfigurerats för kaskadborttagningar. I det här fallet tas inläggen dock bort av databasen eftersom den har konfigurerats med ON DELETE CASCADE när den skapades.

Begränsningar för kaskadfunktioner i databaser

Vissa databaser, framför allt SQL Server, har begränsningar för de kaskadbeteenden som bildar cykler. Tänk till exempel på följande modell:

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; }
}

Den här modellen har tre relationer, alla nödvändiga och därför konfigurerade för att kaskadborttagning enligt konvention.

• Om du tar bort en blogg tas alla relaterade inlägg bort
• Om du tar bort författaren till inlägg kommer de författade inläggen att bli borttagna i en kedja.
• Om du tar bort ägaren till en blogg kommer bloggen att raderas i en kaskadåtgärd.

Allt detta är rimligt (om än lite drakoniskt i blogghanteringspolicys!) men försök att skapa en SQL Server-databas med dessa kaskader konfigurerade resulterar i följande undantag:

Microsoft.Data.SqlClient.SqlException (0x80131904): Införandet av foreign key-villkoret "FK_Posts_Person_AuthorId" i tabellen "Posts" kan orsaka cykler eller flera kaskadsökvägar. Ange VID RADERING INGEN ÅTGÄRD eller VID UPPDATERING INGEN ÅTGÄRD, eller ändra andra BEGRÄNSNINGAR FÖR UTOMNYCKEL.

Det finns två sätt att hantera den här situationen:

1. Ändra en eller flera av relationerna så att de inte tillåter kaskadborttagning.
2. Konfigurera databasen utan en eller flera av dessa kaskadborttagningar och se sedan till att alla beroende entiteter läses in så att EF Core kan utföra det sammanhängande beteendet.

Genom att använda det första tillvägagångssättet i vårt exempel kan vi göra post-blogg-relationen valfri genom att ge den en nullvärdemöjlig utländsk nyckelegenskap.

public int? BlogId { get; set; }

En valfri relation gör att inlägget kan finnas utan en blogg, vilket innebär att kaskadborttagning inte längre konfigureras som standard. Det innebär att det inte längre finns någon cykel i sammanhängande åtgärder, och databasen kan skapas utan fel på SQL Server.

Med den andra metoden i stället kan vi behålla den bloggägarrelation som krävs och konfigureras för kaskadborttagning, men gör att den här konfigurationen endast gäller för spårade entiteter, inte databasen:

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

Vad händer nu om vi läser in både en person och den blogg de äger och sedan tar bort personen?

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();

EF Core kommer att överlappa borttagningen av ägaren så att bloggen också tas bort:

-- 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;

Men om bloggen inte laddas när ägaren tas bort:

using var context = new BlogsContext();

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

context.Remove(owner);

await context.SaveChangesAsync();

Sedan utlöses ett undantag på grund av brott mot begränsningen för sekundärnyckeln i databasen:

Microsoft.Data.SqlClient.SqlException: DELETE-instruktionen stred mot referensvillkoret "FK_Blogs_People_OwnerId". Konflikten uppstod i databasen "Scratch", tabell "dbo.Blogs", kolumn "OwnerId". Uttalandet har avslutats.

Sammanhängande null-värden

Valfria relationer har nullbara sekundärnyckelegenskaper mappade till nullbara databaskolumner. Det innebär att värdet för främmande nyckeln kan anges till null när det aktuella huvudelementet/föräldern tas bort eller separeras från beroende/underordnad.

Nu ska vi titta igen på exemplen från När sammanhängande beteenden inträffar, men den här gången med en valfri relation som representeras av en nullbar Post.BlogId sekundärnyckelegenskap:

public int? BlogId { get; set; }

Egenskapen för den externa nyckeln kommer att sättas till null för varje inlägg när den relaterade bloggen tas bort. Den här koden är till exempel densamma som tidigare:

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();

Kommer nu att resultera i följande databasuppdateringar när SaveChanges anropas:

-- 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;

På samma sätt, om relationen är avskuren med något av exemplen ovan:

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();

Eller:

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();

Sedan uppdateras inläggen med null-värden för utländska nycklar när SaveChanges anropas.

-- 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;

Se Ändra sekundärnycklar och navigering för mer information om hur EF Core hanterar sekundärnycklar och navigering när deras värden ändras.

Databaser kan också konfigureras för att kaskadera nullvärden på detta sätt när ett huvudobjekt/förälder i en valfri relation tas bort. Detta är dock mycket mindre vanligt än att använda sammanhängande borttagningar i databasen. Om du använder sammanhängande borttagningar och sammanhängande null-värden i databasen på samma gång resulterar det nästan alltid i relationscykler när du använder SQL Server. Mer information om hur du konfigurerar sammanhängande null-värden finns i nästa avsnitt.

Konfigurera sammanhängande beteenden

Kaskadbeteenden konfigureras per relation med hjälp av OnDelete metoden i OnModelCreating. Till exempel:

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

Mer information om hur du konfigurerar relationer mellan entitetstyper finns i Relationer .

OnDelete accepterar ett värde från DeleteBehavior enumet, som visserligen är förvirrande. Den här uppräkningen definierar både EF Cores beteende för spårade entiteter och konfigurationen av kaskadborttagning i databasen när EF används för att skapa schemat.

Påverkan på databasschemat

I följande tabell visas resultatet av varje OnDelete värde för främmande nyckelvillkor som skapats av EF Core-migreringar eller EnsureCreated.

Beteendena ON DELETE NO ACTION (standardinställningen för databasen) och ON DELETE RESTRICT i relationsdatabaser är vanligtvis identiska eller mycket lika. Trots vad NO ACTION kan antyda, medför båda dessa alternativ att referensbegränsningar upprätthålls. Skillnaden, när det finns en, är när databasen kontrollerar begränsningarna. Kontrollera din databasdokumentation för de specifika skillnaderna mellan ON DELETE NO ACTION och ON DELETE RESTRICT i ditt databassystem.

SQL Server stöder ON DELETE RESTRICTinte , så ON DELETE NO ACTION används i stället.

De enda värden som orsakar sammanhängande beteenden i databasen är Cascade och SetNull. Alla andra värden konfigurerar databasen så att den inte överlappar några ändringar.

Påverkan på SaveChanges-beteende

Tabellerna i följande avsnitt beskriver vad som händer med beroende entiteter när huvudentiteten/överordnaden tas bort eller när dess relation till beroende entiteter bryts. Varje tabell omfattar något av:

• Valfria (nullable FK) och obligatoriska (icke-nullable FK) relationer
• När beroenden/underordnade läses in och spåras av DbContext och när de bara finns i databasen

Nödvändig relation med beroende/barn har laddats.

Anteckningar:

• Standardvärdet för nödvändiga relationer som detta är Cascade.
• Om du använder något annat än kaskadborttagning för nödvändiga relationer resulterar det i ett undantag när SaveChanges anropas.
  • Detta är vanligtvis en InvalidOperationException från EF Core eftersom det ogiltiga tillståndet upptäcks i de inlästa beroendetillstånden.
  • ClientNoAction tvingar EF Core att inte kontrollera korrigeringsberoenden innan de skickas till databasen, så i det här fallet utlöser databasen ett undantag som sedan omsluts av DbUpdateException SaveChanges.
  • SetNull avvisas när databasen skapas eftersom sekundärnyckelkolumnen inte kan ogiltigförklaras.
• Eftersom beroendeobjekt/barn läses in tas de alltid bort av EF Core, och de lämnas aldrig kvar för att databasen ska ta bort dem.

Nödvändig relation med beroende personer/barn är inte laddad

Anteckningar:

• Att bryta en förbindelse är inte giltigt här eftersom beroenden/barn inte laddas in.
• Standardvärdet för nödvändiga relationer som detta är Cascade.
• Om du använder något annat än kaskadborttagning för nödvändiga relationer resulterar det i ett undantag när SaveChanges anropas.
  • Vanligtvis är detta en DbUpdateException eftersom beroenden/underordnade inte läses in och därför kan det ogiltiga tillståndet bara upptäckas av databasen. SaveChanges omsluter sedan databasfelet i en DbUpdateException.
  • SetNull avvisas när databasen skapas eftersom sekundärnyckelkolumnen inte kan ogiltigförklaras.

Valfri relation till beroende/anhöriga eller barn som är inlästa

Anteckningar:

• Standardvärdet för valfria relationer som detta är ClientSetNull.
• Beroenden/underordnade tas aldrig bort om inte Cascade eller ClientCascade är konfigurerade.
• Alla andra värden gör att de beroende FK:erna anges till null av EF Core...
  • ... utom ClientNoAction som säger till EF Core att inte röra sekundärnycklarna för beroenden/underordnade när huvudkontot/överordnad tas bort. Databasen genererar därför ett undantag som omsluts som ett DbUpdateException av SaveChanges.

Valfri relation med beroende personer/barn som inte har laddats

Anteckningar:

• Att bryta en förbindelse är inte giltigt här eftersom beroenden/barn inte laddas in.
• Standardvärdet för valfria relationer som detta är ClientSetNull.
• Beroende/familjemedlemmar måste läsas in för att undvika ett databasfel, såvida inte databasen har konfigurerats för att kaskadera ta bort eller nollställa element.