-
DescriptionWhile upgrading from CouchDB 1.7.x to 3.1.x (installed via Docker), I noticed this change in behavior: what works to recover a deleted document on 1.7.x seems to fail on 3.1.x Steps to Reproduce# create db
curl -XPUT "http://localhost:5984/some-db"
# put a doc
rev1=$(curl -XPUT "http://localhost:5984/some-db/foo" -d '{"bar":123}' | jq '.rev' -r)
# delete doc
rev2=$(curl -XDELETE "http://localhost:5984/some-db/foo?rev=${rev1}" | jq '.rev' -r)
# try to undelete: fails, {"error":"conflict","reason":"Document update conflict."}
curl -XPUT "http://localhost:5984/some-db/foo?rev=${rev2}" -d '{"bar":123}' | jq '.rev' -r Expected BehaviourRecover the document, as in previous versions Your EnvironmentDocker image:
|
Beta Was this translation helpful? Give feedback.
Answered by
wohali
Oct 5, 2020
Replies: 1 comment
-
You do not need to specify the deleted rev if you are re-creating a previously deleted document. This example works: curl -XPUT "http://localhost:5984/some-db"
rev1=$(curl -XPUT "http://localhost:5984/some-db/foo" -d '{"bar":123}' | jq '.rev' -r)
rev2=$(curl -XDELETE "http://localhost:5984/some-db/foo?rev=${rev1}" | jq '.rev' -r)
curl -XPUT "http://localhost:5984/some-db/foo" -d '{"bar":123}' | jq '.rev' -r This adheres to the principle of least surprise -- you shouldn't have to have prior knowledge about the tombstone (deleted document)'s |
Beta Was this translation helpful? Give feedback.
0 replies
Answer selected by
maxlath
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
You do not need to specify the deleted rev if you are re-creating a previously deleted document. This example works:
This adheres to the principle of least surprise -- you shouldn't have to have prior knowledge about the tombstone (deleted document)'s
_rev
value just to re-create the document.