问题描述
在使用更新处理程序时修订版本冲突的可能性有多大？在编写强大的更新功能时，是否应该使用冲突处理代码？
How likely is a revision conflict when using an update handler? Should I concern myself with conflict-handling code when writing a robust update function?
如所述，CouchDB 0.10及更高版本允许按需服务器端文档修改。
As described in Document Update Handlers, CouchDB 0.10 and later allows on-demand server-side document modification.
更新处理程序可以处理非JSON格式;但其他主要功能是这些：
Update handlers can process non-JSON formats; but the other major features are these:
- HTTP前端任意复杂的文档修改代码
- 类似的代码不需要为所有可能的客户端写一个DRY架构
- 执行速度更快，更不可能发生修订冲突
- An HTTP front-end to arbitrarily complex document modification code
- Similar code needn't be written for all possible clients—a DRY architecture
- Execution is faster and less likely to hit a revision conflict
我不清楚第三点。在本地执行，更新处理程序将运行得更快，延迟更低。但在有争议的情况下，这并不能保证更新成功。或者更新处理程序是否保证成功更新？
I am unclear about the third point. Executing locally, the update handler will run much faster and with lower latency. But in situations with high contention, that does not guarantee a successful update. Or does the update handler guarantee a successful update?
推荐答案
更新冲突仍然可能当使用更新处理程序时。
由于往返时间减少，更新冲突的机会较低
但不为零。冲突会感觉正常：409的响应代码
与此JSON：
Due to the reduced "round-trip time," the chance of an update conflict is lowerbut not zero. A conflict will feel normal: a 409 response codewith this JSON:
{"error":"conflict","reason":"Document update conflict."}
我使用，
和正在运行的卷曲
I successfully triggered a conflict using the document update handler example,and running curl twice in short succession in the shell.
curl -v -X PUT \
http://localhost:5984/db/_design/app/_update/accumulate/my_doc?amount=10 \
& curl -X PUT \
http://localhost:5984/db/_design/app/_update/accumulate/my_doc?amount=1
卷曲响应（随机）之一是201，另一个是409。
One of the curl responses (randomly) was a 201 and the other a 409.
更新会受到冲突，以及验证失败（ 401未授权，
403 Forbidden 等）
Updates are subject to conflicts, as well as validation failures (401 Unauthorized,403 Forbidden, etc.)
这篇关于CouchDB文档更新处理程序可以获得更新冲突吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！