我正在使用.NET SDK使用DocumentDb API实现乐观并发 .
在几个地方,我发现在强类型模型上有 ETag
是一个坏主意 . 显式地:https://www.google.hr/amp/s/peter.intheazuresky.com/2016/04/28/documentdb-revisited-part-3-concurrency-in-documentdb/amp/
即使github上的官方示例也使用 dynamic/Document
类而不是强类型的类来显示它 .
现在,我不明白为什么不在模型上存储 ETag
?根据文档, ETag
,就像其他资源属性一样(例外是 id
)仅为 get
,并且始终由服务器专门更改 . 参考:https://docs.microsoft.com/en-us/azure/cosmos-db/documentdb-resources#system-vs-user-defined-resources
所以,如果我们将 ETag
放在我们的模型上,并且:
-
从db读取文档到具有
etag
属性的强类型模型 -
将其发送到客户端(为简单起见,我们忽略表示层
dto
s) -
客户端更新它并发回
-
我们将更新/替换发送到cosmosdb(将
AccessCondition
设置为etag
从客户端获取并仍然在其中一个模型属性中)
我很难在那里找到问题?为什么要麻烦 dynamics/Document
?
或者我错过了一些明显的东西?
1 回答
Etag是服务器构造,最初你的文档没有它 . 恕我直言,这是一个关于你想要如何纯粹的文件的问题 .
如示例所示,您可以拥有ETag并拥有纯对象(theOrder)
var theOrder =(Order)(dynamic)orderDoc;
Debug.WriteLine( theOrder .Customer.FirstName“.Etag” orderDoc .ETag);
根据上面的示例,您必须保留返回的文档对象以获取ETag,或者您是否应该使用Etag属性 theOrder 对象,在您达到并发之前没有人关心和理解 .