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.
