2009-05-12 7 views
0

私はasp.net MVCアプリケーションでオプティミスティックロックを実装しようとしているだけでなく、監査の末尾を提供しています。linq datacontextアタッチシナリオのGetModifiedMembers

監査フレームワークは、SubmitChangesの実行中にDataContext.GetModifiedMembersを呼び出すことができます。

オプティミスティック・ロックは、ROWVERSIONタイムスタンプを使用して、base64にシリアライズされ、ビュー内の非表示フィールドに配置されます。

私の編集アクションは、次のようになります

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

これは監査で動作するが、楽観的ロックに失敗しました。 UpdateModelが(明らかに読み込み専用の)concurrentTSフィールドを変更しているため、ChangeConflictExceptionではなくInvalidOperationExceptionが発生します。

私は間違っていますか?

答えて

0

これまでの進捗状況は、最後の部分を実行してInvalidOperationExceptionをキャッチし、「値 'ConcurrencyTimestamp'」のテキストを探し、それをChangeConflictExceptionとして再実行することから成り立っています。

これはやっているようですが、かわいいわけではありません。

関連する問題