Dela via

Objekttillstånd och ändringsspårning

  • Artikel

LINQ till SQL-objekt deltar alltid i något tillstånd. När LINQ till SQL till exempel skapar ett nytt objekt är objektet i Unchanged tillstånd. Ett nytt objekt som du själv skapar är okänt för DataContext och är i Untracked tillstånd. Efter en lyckad körning av SubmitChangesär alla objekt som är kända för LINQ till SQL i Unchanged tillstånd. (Det enda undantaget representeras av de som har tagits bort från databasen, som är i Deleted tillstånd och oanvändbara i den DataContext instansen.)

Objekttillstånd

I följande tabell visas möjliga tillstånd för LINQ till SQL-objekt.

Stat/län beskrivning
Untracked Ett objekt som inte spåras av LINQ till SQL. Exempel omfattar följande:

– Ett objekt som inte efterfrågas via den aktuella DataContext (till exempel ett nyligen skapat objekt).
– Ett objekt som skapats via deserialisering
– Ett objekt som efterfrågas via en annan DataContext.
Unchanged Ett objekt som hämtats med hjälp av aktuellt DataContext objekt och som inte är känt för att ha ändrats sedan det skapades.
PossiblyModified Ett objekt som är kopplat till en DataContext. Mer information finns i Datahämtning och CUD-åtgärder i N-nivåprogram (LINQ till SQL).
ToBeInserted Ett objekt som inte hämtas med hjälp av den aktuella DataContext. Detta orsakar en databas INSERT under SubmitChanges.
ToBeUpdated Ett objekt som är känt för att ha ändrats sedan det hämtades. Detta orsakar en databas UPDATE under SubmitChanges.
ToBeDeleted Ett objekt som markerats för borttagning, vilket orsakar en databas DELETE under SubmitChanges.
Deleted Ett objekt som har tagits bort i databasen. Det här tillståndet är slutgiltigt och tillåter inte ytterligare övergångar.

Infoga objekt

Du kan uttryckligen begära Inserts med hjälp InsertOnSubmitav . Alternativt kan LINQ till SQL härleda Inserts genom att hitta objekt som är anslutna till ett av de kända objekt som måste uppdateras. Om du till exempel lägger till ett Untracked objekt i ett EntitySet<TEntity> eller anger ett EntityRef<TEntity> till ett Untracked objekt, gör Untracked du objektet åtkomligt genom att spåra objekt i diagrammet. Under bearbetningen SubmitChangespasserar LINQ till SQL de spårade objekten och identifierar alla beständiga objekt som inte spåras. Sådana objekt är kandidater för infogning i databasen.

För klasser i en arvshierarki InsertOnSubmitanger (o) även värdet för den medlem som har angetts som diskriminerande för att matcha typen av objektet o. Om en typ matchar standarddiskrimineringsvärdet, gör den här åtgärden att det diskriminerande värdet skrivs över med standardvärdet. Mer information finns i Arvsstöd.

Viktigt!

Ett objekt som läggs till i en Table finns inte i identitetscacheminnet. Identitetscacheminnet återspeglar bara vad som hämtas från databasen. Efter ett anrop till InsertOnSubmitvisas inte den tillagda entiteten i frågor mot databasen förrän SubmitChanges den har slutförts.

Ta bort objekt

Du markerar ett spårat objekt o för borttagning genom att anropa DeleteOnSubmit(o) på lämplig Table<TEntity>. LINQ till SQL betraktar borttagningen av ett objekt från en EntitySet<TEntity> uppdateringsåtgärd och motsvarande sekundärnyckelvärde är inställt på null. Målet för åtgärden (o) tas inte bort från tabellen. Indikerar till exempel cust.Orders.DeleteOnSubmit(ord) en uppdatering där relationen mellan cust och ord avbryts genom att ange sekundärnyckeln ord.CustomerID till null. Det orsakar inte borttagningen av raden som motsvarar ord.

LINQ till SQL utför följande bearbetning när ett objekt tas bort (DeleteOnSubmit) från tabellen:

  • När SubmitChanges anropas utförs en DELETE åtgärd för objektet.

  • Borttagningen sprids inte till relaterade objekt oavsett om de läses in. Mer specifikt läses inte relaterade objekt in för uppdatering av relationsegenskapen.

  • När körningen av SubmitChangeshar slutförts anges objekten Deleted till tillståndet . Därför kan du inte använda objektet eller dess id i det DataContext. Den interna cachen som underhålls av en DataContext instans eliminerar inte objekt som hämtas eller läggs till som nya, även efter att objekten har tagits bort i databasen.

Du kan bara anropa DeleteOnSubmit på ett objekt som spåras av DataContext. För ett Untracked objekt måste du anropa Attach innan du anropar DeleteOnSubmit. Att anropa DeleteOnSubmit ett Untracked objekt utlöser ett undantag.

Kommentar

Om du tar bort ett objekt från en tabell uppmanas LINQ till SQL att generera ett motsvarande SQL-kommando DELETE vid tidpunkten SubmitChangesför . Den här åtgärden tar inte bort objektet från cachen eller sprider borttagningen till relaterade objekt.

Om du vill frigöra ett borttaget id objekt använder du en ny DataContext instans. För rensning av relaterade objekt kan du använda funktionen för borttagning av överlappande objekt i databasen eller ta bort relaterade objekt manuellt.

De relaterade objekten behöver inte tas bort i någon särskild ordning (till skillnad från i databasen).

Uppdatera objekt

Du kan identifiera Updates genom att observera meddelanden om ändringar. Meddelanden tillhandahålls via PropertyChanging händelsen i egenskapsuppsättningar. När LINQ till SQL meddelas om den första ändringen av ett objekt skapar det en kopia av objektet och tar hänsyn till objektet som en kandidat för att generera en Update -instruktion.

För objekt som inte implementerar INotifyPropertyChangingunderhåller LINQ till SQL en kopia av de värden som objekten hade när de först materialiserades. När du anropar SubmitChangesjämför LINQ till SQL de aktuella och ursprungliga värdena för att avgöra om objektet har ändrats.

För uppdateringar av relationer betraktas referensen från det underordnade till den överordnade (det vill: referensen som motsvarar den främmande nyckeln) som utfärdare. Referensen i omvänd riktning (dvs. från överordnad till underordnad) är valfri. Relationsklasser (EntitySet<TEntity> och EntityRef<TEntity>) garanterar att de dubbelriktade referenserna är konsekventa för en-till-många- och en-till-en-relationer. Om objektmodellen inte använder EntitySet<TEntity> eller EntityRef<TEntity>, och om den omvända referensen finns, är det ditt ansvar att hålla den konsekvent med referensen framåt när relationen uppdateras.

Om du uppdaterar både den nödvändiga referensen och motsvarande sekundärnyckel måste du se till att de samtycker. Ett InvalidOperationException undantag utlöses om de två inte synkroniseras vid den tidpunkt då du anropar SubmitChanges. Även om ändringar av sekundärnyckelvärden är tillräckliga för att påverka en uppdatering av den underliggande raden, bör du ändra referensen för att upprätthålla anslutningen för objektdiagrammet och dubbelriktad konsekvens för relationer.

Se även