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?
As described in Document Update Handlers, CouchDB 0.10 and later allows on-demand server-side document modification.
Update handlers can process non-JSON formats; but the other major features are these:
- 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?
Update conflicts are still possible when using update handlers.
Due to the reduced "round-trip time," the chance of an update conflict is lower
but not zero. A conflict will feel normal: a 409 response code
with 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
One of the curl responses (randomly) was a 201 and the other a 409.
Document update handlers do not fundamentally change CouchDB
Updates are subject to conflicts, as well as validation failures (401 Unauthorized,
403 Forbidden, etc.)
