首页 文章

将ETag添加到强类型模型真的是个坏主意吗？

提问于
浏览 次
1

我正在使用.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 ？

或者我错过了一些明显的东西？

azure azure-cosmosdb optimistic-concurrency

1 回答

  • 1

    Etag是服务器构造，最初你的文档没有它 . 恕我直言，这是一个关于你想要如何纯粹的文件的问题 .

    如示例所示，您可以拥有ETag并拥有纯对象（theOrder）

    var theOrder =（Order）（dynamic）orderDoc;

    Debug.WriteLine（ theOrder .Customer.FirstName“.Etag” orderDoc .ETag）;

    根据上面的示例，您必须保留返回的文档对象以获取ETag，或者您是否应该使用Etag属性 theOrder 对象，在您达到并发之前没有人关心和理解 .

    回复于

相关问题