Attach 场景中的 linq datacontext GetModifiedMembers
我正在尝试在 asp.net MVC 应用程序中实现乐观锁定，并提供审核跟踪。
审计框架依赖于能够在 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);
}
这适用于审计，但乐观锁定失败。 我得到的不是 ChangeConflictException，而是 InvalidOperationException，因为 UpdateModel 正在更改并发TS 字段（显然是只读的）。
我究竟做错了什么？
I am trying to implement Optimistic Locking in an asp.net MVC application, as well as provide audit trailing.
The audit framework relies on being able to call DataContext.GetModifiedMembers during SubmitChanges, which makes good sense, i guess.
The optimistic locking uses ROWVERSION timestamps, serialized to base64 and put in a hidden field in the view.
My Edit action looks like this:
[AcceptVerb(HttpVerb.Post)]
public ActionResult Edit(MyType myType)
{
context.MyTypes.Attach(myType, true);
context.SubmitChanges(ConflictMode.FailOnFirstConflict);
}
When doing this, the DataContext.GetModifiedMembers will always return ALL the properties on MyType, rather than just the ones that are changed between the database and the values provided, which breaks the auditing.
Specifically it returns every property as having been changed from their new value to their new value, so its not even like I can do anything clever to the list.
I tried loading the object first, before attaching it, but this gives a duplicate key exception.
I then tried using UpdateModel, i.e.
[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);
}
This works with the auditing, but fails the optimistic locking.
Rather than a ChangeConflictException i get an InvalidOperationException because the UpdateModel is changing the concurrentTS field (which apparently is readonly).
What am I doing wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
到目前为止的进展包括完成最后一部分，捕获 InvalidOperationException 并查找文本“成员‘ConcurrencyTimestamp’的值”，并将其作为 ChangeConflictException 重新抛出。
这似乎可以解决问题，但并不漂亮。
Progress so far consists of doing the last part, and catching InvalidOperationException and looking for the text "Value of member 'ConcurrencyTimestamp'", and rethrowing that as a ChangeConflictException.
That seems to do the trick, but it is not pretty.