Objectstatussen en wijzigingen bijhouden
LINQ naar SQL-objecten nemen altijd deel aan een bepaalde status. Wanneer LINQ naar SQL bijvoorbeeld een nieuw object maakt, heeft Unchanged
het object de status. Een nieuw object dat u zelf maakt, is onbekend en heeft Untracked
de DataContext status. Na een geslaagde uitvoering van SubmitChanges, bevinden alle objecten die bekend zijn bij LINQ naar SQL, de Unchanged
status. (De enkele uitzondering wordt vertegenwoordigd door degenen die zijn verwijderd uit de database, die in Deleted
staat zijn en onbruikbaar zijn in dat DataContext exemplaar.)
Objectstatussen
De volgende tabel bevat de mogelijke statussen voor LINQ naar SQL-objecten.
Provincie | Beschrijving |
---|---|
Untracked |
Een object dat niet wordt bijgehouden door LINQ naar SQL. Hier volgen enkele voorbeelden: - Een object dat niet wordt opgevraagd via de huidige DataContext query (zoals een nieuw gemaakt object). - Een object dat is gemaakt via deserialisatie - Een object dat wordt opgevraagd via een andere DataContext. |
Unchanged |
Een object dat is opgehaald met behulp van de huidige DataContext en niet bekend is gewijzigd sinds het is gemaakt. |
PossiblyModified |
Een object dat is gekoppeld aan een DataContext. Zie Gegevens ophalen en CUD-bewerkingen in N-tier-toepassingen (LINQ naar SQL) voor meer informatie. |
ToBeInserted |
Een object dat niet wordt opgehaald met behulp van de huidige DataContext. Dit veroorzaakt een database INSERT tijdens SubmitChanges. |
ToBeUpdated |
Een object dat bekend is gewijzigd sinds het is opgehaald. Dit veroorzaakt een database UPDATE tijdens SubmitChanges. |
ToBeDeleted |
Een object dat is gemarkeerd voor verwijdering, waardoor een database DELETE tijdens SubmitChanges. |
Deleted |
Een object dat in de database is verwijderd. Deze status is definitief en staat geen extra overgangen toe. |
Objecten invoegen
U kunt expliciet aanvragen Inserts
met behulp van InsertOnSubmit. LinQ naar SQL kan ook afleiden Inserts
door objecten te vinden die zijn verbonden met een van de bekende objecten die moeten worden bijgewerkt. Als u bijvoorbeeld een Untracked
object toevoegt aan een EntitySet<TEntity> of een EntityRef<TEntity> object instelt op een Untracked
object, maakt u het Untracked
object bereikbaar via bijgehouden objecten in de grafiek. Tijdens de verwerking SubmitChangesdoorkruist LINQ naar SQL de bijgehouden objecten en detecteert u eventuele bereikbaar permanente objecten die niet worden bijgehouden. Dergelijke objecten zijn kandidaten voor invoeging in de database.
Voor klassen in een overnamehiërarchie InsertOnSubmitstelt (o
) ook de waarde in van het lid dat is aangewezen als de discriminator die overeenkomt met het type van het object o
. In het geval van een type dat overeenkomt met de standaarddiscriminatorwaarde, zorgt deze actie ervoor dat de discriminatorwaarde wordt overschreven met de standaardwaarde. Zie Overnameondersteuning voor meer informatie.
Belangrijk
Een object dat aan een Table
object is toegevoegd, bevindt zich niet in de identiteitscache. De identiteitscache geeft alleen weer wat uit de database wordt opgehaald. Na een aanroep naar InsertOnSubmit, wordt de toegevoegde entiteit pas weergegeven in query's voor de database als SubmitChanges deze is voltooid.
Objecten verwijderen
U markeert een bijgehouden object o
voor verwijdering door (o) aan te roepen DeleteOnSubmitop de betreffende Table<TEntity>. LINQ naar SQL beschouwt het verwijderen van een object uit een EntitySet<TEntity> updatebewerking en de bijbehorende refererende-sleutelwaarde is ingesteld op null. Het doel van de bewerking (o
) wordt niet verwijderd uit de tabel. Geeft bijvoorbeeld cust.Orders.DeleteOnSubmit(ord)
een update aan waarbij de relatie tussen cust
en ord
wordt verbroken door de refererende sleutel ord.CustomerID
in te stellen op null. Dit veroorzaakt geen verwijdering van de rij die overeenkomt met ord
.
LINQ naar SQL voert de volgende verwerking uit wanneer een object wordt verwijderd (DeleteOnSubmit) uit de tabel:
Wanneer SubmitChanges wordt aangeroepen, wordt een
DELETE
bewerking voor dat object uitgevoerd.De verwijdering wordt niet doorgegeven aan gerelateerde objecten, ongeacht of ze worden geladen. Gerelateerde objecten worden niet geladen voor het bijwerken van de relatie-eigenschap.
Nadat de uitvoering is SubmitChangesvoltooid, worden de objecten ingesteld op de
Deleted
status. Als gevolg hiervan kunt u het object of de bijbehorendeid
eigenschap niet gebruiken.DataContext De interne cache die door een DataContext exemplaar wordt onderhouden, elimineert geen objecten die als nieuw worden opgehaald of toegevoegd, zelfs nadat de objecten in de database zijn verwijderd.
U kunt alleen een object aanroepen DeleteOnSubmit dat wordt bijgehouden door de DataContext. Voor een Untracked
object moet u aanroepen Attach voordat u aanroept DeleteOnSubmit. Als u een Untracked
object aanroeptDeleteOnSubmit, wordt er een uitzondering gegenereerd.
Notitie
Als u een object uit een tabel verwijdert, wordt LINQ aan SQL door gegeven om een bijbehorende SQL-opdracht DELETE
te genereren op het moment van SubmitChanges. Met deze actie wordt het object niet uit de cache verwijderd of wordt de verwijdering doorgegeven aan gerelateerde objecten.
Als u het id
verwijderen van een verwijderd object wilt terugvorderen, gebruikt u een nieuw DataContext exemplaar. Voor het opschonen van gerelateerde objecten kunt u de functie trapsgewijs verwijderen van de database gebruiken of de gerelateerde objecten handmatig verwijderen.
De gerelateerde objecten hoeven niet in een speciale volgorde te worden verwijderd (in tegenstelling tot in de database).
Objecten bijwerken
U kunt detecteren Updates
door meldingen van wijzigingen te observeren. Meldingen worden verstrekt via de PropertyChanging gebeurtenis in eigenschapssetters. Wanneer LINQ naar SQL wordt geïnformeerd over de eerste wijziging in een object, wordt er een kopie van het object gemaakt en wordt het object beschouwd als een kandidaat voor het genereren van een Update
instructie.
Voor objecten die niet worden geïmplementeerd INotifyPropertyChanging, onderhoudt LINQ naar SQL een kopie van de waarden die objecten hadden toen ze voor het eerst werden gerealiseerd. Wanneer u LINQ aanroept SubmitChanges, vergelijkt LINQ met SQL de huidige en oorspronkelijke waarden om te bepalen of het object is gewijzigd.
Voor updates van relaties wordt de verwijzing van het kind naar het bovenliggende item (dat wil gezegd de verwijzing die overeenkomt met de refererende sleutel) beschouwd als de autoriteit. De verwijzing in omgekeerde richting (van bovenliggend naar onderliggend) is optioneel. Relatieklassen (EntitySet<TEntity> en EntityRef<TEntity>) garanderen dat de bidirectionele verwijzingen consistent zijn voor een-op-veel- en een-op-een-relaties. Als het objectmodel geen gebruik maakt EntitySet<TEntity> van of EntityRef<TEntity>, en als de omgekeerde verwijzing aanwezig is, is het uw verantwoordelijkheid om het consistent te houden met de doorstuurverwijzing wanneer de relatie wordt bijgewerkt.
Als u zowel de vereiste verwijzing als de bijbehorende refererende sleutel bijwerkt, moet u ervoor zorgen dat deze overeenkomen. Er wordt een InvalidOperationException uitzondering gegenereerd als de twee niet worden gesynchroniseerd op het moment dat u belt SubmitChanges. Hoewel wijzigingen in de refererende sleutelwaarde voldoende zijn om een update van de onderliggende rij te beïnvloeden, moet u de verwijzing wijzigen om de connectiviteit van de objectgrafiek en bidirectionele consistentie van relaties te behouden.