linq datacontext GetModifiedMembers in Attach Сценарий

Question

Я пытаюсь реализовать Оптимистическую блокировку в asp.net MVC-приложении, а также предоставлять завершающий аудит.

Основы аудита полагаются на возможность вызова DataContext.GetModifiedMembers во время SubmitChanges, что имеет смысл, я думаю.

Оптимистичная блокировка использует временные метки ROWVERSION, сериализованные на base64 и помещенные в скрытое поле в представлении.

My Edit действий выглядит следующим образом:

[AcceptVerb(HttpVerb.Post)] 
public ActionResult Edit(MyType myType) 
{ 
    context.MyTypes.Attach(myType, true); 
    context.SubmitChanges(ConflictMode.FailOnFirstConflict); 
} 

При выполнении этого, DataContext.GetModifiedMembers всегда будет возвращать все свойства на MyType, а не только те, которые изменяются между базой данных и при условии, что значения , что нарушает аудит. В частности, он возвращает каждое свойство как измененное с нового значения на новое значение, поэтому его даже не нравится делать что-нибудь умное в списке.

Я попытался сначала загрузить объект, прежде чем прикреплять его, но это дает дублирующее ключевое исключение.

Затем я попытался с помощью UpdateModel, т.е.

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

Это работает с ревизии, но не может оптимистическую блокировку. Вместо исключения ChangeConflictException возникает исключение InvalidOperationException, потому что UpdateModel меняет поле concurrentTS (которое, по-видимому, является только для чтения).

Что я делаю неправильно?

Answer 1

Прогресс до сих пор состоит из выполнения последней части и обнаружения InvalidOperationException и поиска текста «Значение элемента« ConcurrencyTimestamp »» и повторное его преобразование как исключение ChangeConflictException.

Это похоже на трюк, но это не очень.