Hej,

Mitt problem är följande:

Jag laddar in ett gäng poster från databasen (Personer enligt ett visst urval) in i en collection (List<> eller liknande). Denna lista kommer jag nu att jobba med: Några poster kanske läggs till, några uppdateras och några kanske raderas. Nu när jag är klar med mina ändringar vill jag så klart uppdatera databasen med ändringarna. Inga problem. Jag anropar en Update-metod:

base.Persons.InsertAllOnSubmit(urval) lägger till poster. Urvalet görs på de poster utan ID t.ex.
Sen kör jag base.SubmitChanges() som uppdaterar allt.

Men hur gör jag med de raderade posterna? Posterna finns ju inte i min collection längre och LINQ fattar ju inte att de är borttagna eftersom de inte finns. Jag skulle förvisso kunna anropa base.Persons.DeleteOnSubmit(Person) varje gång jag tar bort något från min collection men det känns ju inte så bra. Jag vill ju bara göra ett uppdateringsanrop till datalagret.

Måste jag spara ner alla mina deletes i en separat collection som jag skickar med till Update-funktionen? Eller ska man flagga alla poster med Delete vilket innebär att jag måste lägga på ett nytt fält på mina enities? Eller ska jag hålla reda på alla mina Deletes i en separat collection och anropa datalagret två gånger? Känns ju heller inte speciellt bra.

Hur ska man göra?

/Raymond

Jag har stött på samma problem själv. Det är förmodligen helt fel väg att gå, men jag har valt att lägga till en DeletedPersonIDs-lista, och skicka med den.

Det vettiga är ju egentligen att "samlingen" är något som förstår och håller reda på vad som händer, men sen kommer det ju in större transaktionsfrågor.

Som jag skrev i en annan tråd kan man ju se det på två sätt, antingen är min lista "the lista". Alltså, finns det inte i min lista, så finns det inte, och då ska det tas bort. Eller så är min lista en lista på de jag råkar känna till. Då måste jag hantera alla borttagna som att "den här har jag tagit bort".

Men vad betyder det att något är borttaget egentligen?
T.ex. om någon annan har ändrat samma post under tiden.
Hela problemet sväller över och det är inte bara på db-transaktionsnivå. Ett vettigt synsätt som jag gillar är den optimistic concurrency som finns i t.ex. SVN. Det kräver mer tänk kring vad som ska hända i olika fall, men alternativet är ju att inte tänka på det alls.


Jag känner hela tiden att jag växlar mellan att ha förstått och inte ha förstått. Är det någon som har en riktigt bra resurs för hur man ska tänka?

Hej,

Jo, en ytterligare lista som håller de raderade posterna verkar ju vettigt - men samtidigt helt sjukt. Jag kan leva med en sådan lösning men vad är best practice...

Det måste väl vara ett vanligt förekommande sätt att jobba på - att man jobbar med sin mängd med entiteter (CUD) för att slutligen uppdatera dessa i ett anrop till ett datalager. Det är ju därmed inte ett LINQ-relaterat problem.

/Raymond