检查附件是否与 couchdb 中的当前文档版本保持同步
Check if attachment is up to date with current document revision in couchdb
在我的应用程序中，我 post 通过监听更改流来处理 couchdb 文档。场景如下：
- 我的应用程序通过 /db/_changes
收到文档已更改的通知
- 它获取文档并检查文档是否有适当的附件以及附件的
revpos 是否等于文档版本的第一部分。例如，如果 rev 看起来像这样 13-D2JDBS3 那么我在 - 字符处拆分字符串，获取第一个匹配项，将其转换为数字并将其与附件的 revpos 进行比较.
- 如果上述检查失败，我会生成 PDF 并将其附加到文档中。
目前效果还不错。但我想知道这是否是 couchdb 的设计有意为之。依赖这种行为是否安全（revpos 反映了它所属的修订版的第一部分）？我在文档中找不到任何相关内容。
提前感谢有关此主题的任何提示。
我认为这是故意的并且似乎是 public 并记录在案 API，尽管措辞可能需要一些澄清。
在 Revisions documentation 他们说：
The revision number is the MD5 hash of the transport representation of a document with an N- prefix denoting the number of times a document got updated.
在 Attachments documentation 他们说：
revpos (number): Revision number when attachment was added [emphasis theirs]
有点不幸的是，他们在之前的文档中将 whole _rev 标识符称为 "revision number"，因为很明显后者只是将 "N" 前缀突出显示为“number”。
您可以考虑就此提交文档错误，要求他们澄清 revpos 将始终是 "N- prefix" 的 "N" 部分，如果这确实是他们愿意保证的。
在我的应用程序中，我 post 通过监听更改流来处理 couchdb 文档。场景如下：
- 我的应用程序通过 /db/_changes 收到文档已更改的通知
- 它获取文档并检查文档是否有适当的附件以及附件的
revpos是否等于文档版本的第一部分。例如，如果 rev 看起来像这样13-D2JDBS3那么我在-字符处拆分字符串，获取第一个匹配项，将其转换为数字并将其与附件的revpos进行比较. - 如果上述检查失败，我会生成 PDF 并将其附加到文档中。
目前效果还不错。但我想知道这是否是 couchdb 的设计有意为之。依赖这种行为是否安全（revpos 反映了它所属的修订版的第一部分）？我在文档中找不到任何相关内容。
提前感谢有关此主题的任何提示。
我认为这是故意的并且似乎是 public 并记录在案 API，尽管措辞可能需要一些澄清。
在 Revisions documentation 他们说：
The revision number is the MD5 hash of the transport representation of a document with an N- prefix denoting the number of times a document got updated.
在 Attachments documentation 他们说：
revpos (number): Revision number when attachment was added [emphasis theirs]
有点不幸的是，他们在之前的文档中将 whole _rev 标识符称为 "revision number"，因为很明显后者只是将 "N" 前缀突出显示为“number”。
您可以考虑就此提交文档错误，要求他们澄清 revpos 将始终是 "N- prefix" 的 "N" 部分，如果这确实是他们愿意保证的。