Szabo, Viktor (2012-02-20 21:16): > Hi, > > An application we have is using bulk writes to insert objects into the > database, and occasionally some > documents get lost. It turns out this happens for the very same reason > described below. If we're > re-insering a doc using an id that has been deleted earlier, if the contents > match the payload that was > saved when the id got used for the first time, the doc remains in "deleted" > state and the client > gets a misleading response. This only happens when the database is compacted > after the delete operation > is executed. > > I still feel that this is pretty nasty - what do you guys think? > > Looking at the reply coming from _bulk_docs, there's no way I can tell if I > can read back my doc from the database or not.
This is a bug and it would be nice if you could report it to JIRA. I can also reproduce it with the latest CouchDB version from git (and this seems not really related to _bulk_docs): alias curl='curl -H "Content-Type: application/json"' url="http://localhost:5984/database"; 1 curl -X PUT $url 2 curl -X POST $url -d '{"_id": "bug", "key": "value"}' 3 curl -X DELETE "$url/bug?rev=1-59414e77c768bc202142ac82c2f129de" 4 curl -X POST "$url/_compact" 5 curl -X POST $url -d '{"_id": "bug", "key": "value"}' 6 curl -X GET "$url/bug" (bug here) 1 {"ok":true} 201 2 [{"ok":true,"id":"bug","rev":"1-59414e77c768bc202142ac82c2f129de"}] 201 3 {"ok":true,"id":"bug","rev":"2-9b2e3bcc3752a3a952a3570b2ed4d27e"} 200 4 {"ok":true} 202 5 [{"ok":true,"id":"bug","rev":"1-59414e77c768bc202142ac82c2f129de"}] 201 6 {"error":"not_found","reason":"deleted"} 404 CouchDB shouldn't report "ok" on step 5 and then go on to claim that the doc is deleted. Also, it seems to work on second try: 7 curl -X POST $url -d '{"_id": "bug", "key": "value"}' 8 curl -X GET "$url/bug" 7 {"ok":true,"id":"bug","rev":"3-674f864b73df1c80925e48436e21d550"} 201 8 {"_id":"bug","_rev":"3-674f864b73df1c80925e48436e21d550","key":"value"} 200 -- -- Rogutės Sparnuotos
