Ich versuche, Optimistic Locking in einer asp.net MVC-Anwendung zu implementieren, und Audit Trailing bereitzustellen.linq datacontext GetModifiedMembers in Attach-Szenario
Das Audit-Framework beruht darauf, DataContext.GetModifiedMembers während SubmitChanges aufrufen zu können, was sinnvoll ist, denke ich.
Das optimistische Sperren verwendet ROWVERSION-Zeitstempel, serialisiert nach base64 und in ein verstecktes Feld in der Ansicht.
Meine Aktion bearbeiten sieht wie folgt aus:
[AcceptVerb(HttpVerb.Post)]
public ActionResult Edit(MyType myType)
{
context.MyTypes.Attach(myType, true);
context.SubmitChanges(ConflictMode.FailOnFirstConflict);
}
Wenn dies tun, werden die DataContext.GetModifiedMembers immer alle Eigenschaften auf MyType zurückkehren, und nicht nur diejenigen, die zwischen der Datenbank und die Werte zur Verfügung gestellt geändert werden , die das Auditing bricht. Insbesondere gibt es jede Eigenschaft zurück, die von ihrem neuen Wert zu ihrem neuen Wert geändert worden ist, also ist es nicht einmal so, als ob ich etwas schlaues an der Liste machen könnte.
Ich habe versucht, das Objekt zuerst zu laden, bevor Sie es anfügen, aber dies gibt eine doppelte Schlüssel Ausnahme.
Ich habe dann versucht Update verwenden, das heißt
[AcceptVerb(HttpVerb.Post)]
public ActionResult Edit(int id, FormCollection col)
{
var mt = context.MyTypes.Single(mt => mt.id = id);
UpdateModel(mt);
context.SubmitChanges(ConflictMode.FailOnFirstConflict);
}
Dies funktioniert mit der Prüfung, aber nicht die optimistische Sperr. Anstatt einer ChangeConflictException erhalte ich eine InvalidOperationException, weil das UpdateModel das Feld concurrentTS (das anscheinend nur gelesen wird) ändert.
Was mache ich falsch?