What happens if you change the document? For example if you insert a field with a timestamp as in:
$ curl -X PUT -H "Content-type: application/json" http://hostname:7002/test/dummy -d '{ "_id": "dummy", "a": "'$(date +%s)'" }' Marcello 2011/11/22 Szabo, Viktor (Enterprise Infrastructure) <[email protected]>: > The very same thing happens: > > $ curl -X POST -H "Content-type: application/json" > http://hostname:7002/test/_compact > {"ok":true} > $ curl -X PUT -H "Content-type: application/json" > http://hostname:7002/test/dummy -d '{ "_id": "dummy" }' > {"ok":true,"id":"dummy","rev":"1-967a00dff5e02add41819138abb3284d"} > > By the way, I've been using the API doc found over here: > http://www.couchbase.org/sites/default/files/uploads/all/documentation/couchbase-api-dbdoc.html#couchbase-api-dbdoc_db_post > > Shouldn't I? > > Thanks, > Viktor > > -----Original Message----- > From: Robert Newson [mailto:[email protected]] > Sent: 22 November 2011 14:28 > To: [email protected] > Subject: Re: possible compact bug in 1.1.1 > > When couch requires a Referer header it is expecting form-data not json. So > it could be you have found a bug there. I'd call it serious if you can induce > the same thing with the correct input format. > > Use PUT instead of POST, drop the referer header and let us know what happens. > > Sent from my iPhone > > On 22 Nov 2011, at 10:44, "Szabo, Viktor (Enterprise Infrastructure)" > <[email protected]> wrote: > >> Hi CouchDB users, >> >> I don't know if this is a known issue or not, but I've been >> experiencing strange behaviour in version 1.1.1 after initiating >> compaction. Even though there's already a doc with the _id value of >> "dummy" in my database, if I want to have it re-inserted after a compact >> operation is started, 9 times out of 10, I receive an "ok":true >> notification. Occasionally I'm seeing the expected conflict error. >> >> $ curl -X POST -H "Content-type: application/json" >> http://hostname:7002/test/_compact >> {"ok":true} >> $ curl -X POST -H "Content-type: application/json" -H "Referer: >> http://hostname:7002/"; http://hostname:7002/test -d '{ "_id": "dummy" }' >> {"ok":true,"id":"dummy","rev":"1-967a00dff5e02add41819138abb3284d"} >> $ curl -X POST -H "Content-type: application/json" >> http://hostname:7002/test/_compact >> {"ok":true} >> $ curl -X POST -H "Content-type: application/json" -H "Referer: >> http://hostname:7002/"; http://hostname:7002/test -d '{ "_id": "dummy" }' >> {"ok":true,"id":"dummy","rev":"1-967a00dff5e02add41819138abb3284d"} >> How is this possible? >> >> Given that I sometimes get an "ok" confirmation, but sometimes get a >> "conflict error" for the very same request sent to the database with the >> very same content, I don't really feel secure about the integrity of the >> service. >> I'm thinking that the issue is related to the fact that the database >> already had accepted a doc with the same id and content, but still, >> undeterministic behaviour is not something I like. >> >> Do you have a clue on what might be going on? >> >> (I wasn't able to reproduce under 1.1.0. Used a single-node instance >> with no replication set up and no clients connecting to the service) >> >> Thanks, >> Viktor >> >> ---------------------------------------------------------------------- >> ---- >> 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. > > -------------------------------------------------------------------------- > 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.
