O数据与并发令牌
我正在构建一个应用程序，需要能够离线存储数据并将其同步到 OData 服务器。在查看视频时，其中一位演示者提到了一个并发令牌 - 该令牌可以用来帮助同步过程吗？如果可以的话，该如何使用以及需要注意什么？
有关详细信息，我的目标平台是 Android，因此我无法使用 Microsoft Sync Framework。
I'm building an application that needs to be able to store data offline and sync it to an OData server. While reviewing the videos, one of the presenters mentioned a Concurrency Token - can this token be used to help in the sync process? If so, how do I use it and what do I need to watch out for?
For further info, my target platform is Android, so I'm unable to use the Microsoft Sync Framework.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
并发令牌，也称为 ETag（根据 HTTP RFC），可以想象为实体实例的版本号。每当实体发生变化时，服务器都会发出该消息。服务器将其与实体一起发送到客户端，并且客户端可以在应用更改时将其发送回服务器（在 If-Match 标头中）。然后，服务器将检查客户端是否具有最新版本，如果是，则应用更改。否则更新请求失败。
它可以通过两种方式帮助您完成同步过程：
如果您从服务器获取一个实体，并且它的 ETag 与客户端记住的不同，则服务器实例已更改，因此您可以更新客户端实例，或者在客户端进行更改时执行一些冲突解决方案。
另一种方法是将所有更改从客户端发送到服务器（使用正确的 ETag），服务器将使所有已在服务器上更改的更改失败。然后客户端可以从服务器获取新版本，解决冲突并重试。
但请注意，除非您的 ETag 是实体上可公开访问的属性之一，否则没有内置方法可以过滤 ETag，因此目前您无法要求服务器获取自给定版本以来更改的所有实体。尽管如果您确实控制服务，您也许能够做到这一点（有一个全局版本号，每次更改都会引发该版本号，并且每个实体都携带上次对其进行的更改的版本号，然后您可以过滤该版本属性） 。
The concurrency token, also called the ETag (as per the HTTP RFC) can be imagined as a version number of the entity instance. The server raises that every time the entity changes. The server sends this along with the entity to the client and the client can send it back to the server (in the If-Match header) when applying changes. The server will then check that the client has the latest version and if so applies the change. Otherwise it fails the update request.
It can help you with the sync process in two ways:
If you get an entity from the server and it has a differente ETag from what your client remembers, the server instance chas changed, so you may either update the client instance or perform some conflict resolution if the client made changes.
The other way would be to send all the changes from the client to the server (With the right ETags) and the server will fail all of those which already changed on the server. The client can then get the new versions from the server, resolve conflicts and try again.
Note though, that unless your ETag is one of the publicly accesible properties on the entity, there is no built-in way to filter on the ETag, so currently you can't ask the server to get you all entities changed since a given version. Although if you do control the service, you might be able to do this (have a global version number and each change raises that and each entity carries the version number of the last change made to it, then you can filter on that version property).