couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Szabo, Viktor" <Viktor.Sz...@morganstanley.com>
Subject RE: possible compact bug in 1.1.1
Date Tue, 21 Feb 2012 16:56:41 GMT
Hi Rogutės,

Thanks, I've just created a ticket under COUCHDB-1415.

I've marked it as "Major" although it could be considered "Critical" given the fact
one might lose the data thinking it's stored into the database while it's not.

Thanks,
Viktor

-----Original Message-----
From: Rogutės Sparnuotos [mailto:rogutes@googlemail.com] 
Sent: 21 February 2012 14:16
To: user@couchdb.apache.org
Subject: Re: possible compact bug in 1.1.1

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

--------------------------------------------------------------------------
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained
herein are not intended to be, and do not constitute, advice within the meaning of Section
975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received
this communication in error, please destroy all electronic and paper copies and notify the
sender immediately. Mistransmission is not intended to waive confidentiality or privilege.
Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor
electronic communications. This message is subject to terms available at the following link:
http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify
us by reply message and we will send the contents to you. By messaging with Morgan Stanley
you consent to the foregoing.

Mime
View raw message