incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Deleted docs can be accidentally resurrected
Date Fri, 20 Nov 2009 15:25:36 GMT
On Nov 20, 2009, at 5:01 AM, Matt Goodall wrote:

> 2009/11/20 Matt Goodall <matt.goodall@gmail.com>:
>> 2009/11/19 Adam Kocoloski <kocolosk@apache.org>:
>>> On Nov 18, 2009, at 6:51 PM, Matt Goodall wrote:
>>> 
>>>> 2009/11/18 Sebastian Cohnen <sebastiancohnen@googlemail.com>:
>>>>> afaik, this behavior is normal. you just created another (and new) resource/document.
>>>>> 
>>>>> have a look (the database test is new and never contained docs with id
'foo' or 'foobar'):
>>>>> 
>>>>> $ curl -X PUT -d '{"_id": "foo", "_rev": "1-967a00dff5e02add41819138abb3284d",
"num": 1}' "http://localhost:5984/test/foo"
>>>>> {"ok":true,"id":"foo","rev":"2-65371ad05fc99a9b794f68c6003bc8da"}
>>>>> 
>>>>> $ curl -X PUT -d '{"_id": "foobar", "_rev": "4-anythingyouwant", "num":
1}' "http://localhost:5984/test/foobar"
>>>>> {"ok":true,"id":"foobar","rev":"5-084106c9189a346875996e76c1833630"}
>>>> 
>>>> Hmm, seems wrong to me although I can imagine that's useful during
>>>> replication (which doesn't mean it should work for a PUT). However,
>>>> why does the following fail then:
>>>> 
>>>> $ curl -X "PUT" -d '{}' "http://localhost:15984/test/foo"
>>>> {"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"}
>>>> $ curl -X "PUT" -d '{"_id": "foo", "_rev":
>>>> "1-967a00dff5e02add41819138abb3284d"}'
>>>> "http://localhost:15984/test/foo"
>>>> {"ok":true,"id":"foo","rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}
>>>> $ curl -X "DELETE"
>>>> "http://localhost:15984/test/foo?rev=2-7051cbe5c8faecd085a3fa619e6e6337"
>>>> {"ok":true,"id":"foo","rev":"3-7379b9e515b161226c6559d90c4dc49f"}
>>>> $ curl -X "PUT" -d '{"_id": "foo", "_rev":
>>>> "1-967a00dff5e02add41819138abb3284d"}'
>>>> "http://localhost:15984/test/foo"
>>>> {"error":"conflict","reason":"Document update conflict."}
>>>> 
>>>> - Matt
>>>> 
>>>>> 
>>>>> 
>>>>> cheers,
>>>>> 
>>>>> tisba / Sebastian
>>>>> 
>>>>> On 18.11.2009, at 23:56, Matt Goodall wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I swear I've reported this odd behaviour before but I can't find
any
>>>>>> mention of it now ...
>>>>>> 
>>>>>> I have some code with a race condition that is caused by what I
>>>>>> believe is a bug in CouchDB - a deleted document can be updated using
>>>>>> an old, valid rev.
>>>>>> 
>>>>>> If a document has not been deleted then CouchDB correctly returns
a
>>>>>> conflict error if the latest rev is not sent. However, once deleted,
>>>>>> any rev in the docs history can be sent as the update and, as long
as
>>>>>> the doc is changed in some way, the document will be resurrected
with
>>>>>> a rev whose sequence is 1 more than that sent in the update.
>>>>>> 
>>>>>> Create new doc ...
>>>>>> $ curl -X "PUT" -d '{"_id": "foo"}' http://localhost:15984/test/foo
>>>>>> {"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"}
>>>>>> 
>>>>>> Update a couple of times to move the rev on ...
>>>>>> $ curl -X "PUT" -d '{"_id": "foo", "_rev":
>>>>>> "1-967a00dff5e02add41819138abb3284d"}' http://localhost:15984/test/foo
>>>>>> {"ok":true,"id":"foo","rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}
>>>>>> $ curl -X "PUT" -d '{"_id": "foo", "_rev":
>>>>>> "2-7051cbe5c8faecd085a3fa619e6e6337"}' http://localhost:15984/test/foo
>>>>>> {"ok":true,"id":"foo","rev":"3-825cb35de44c433bfb2df415563a19de"}
>>>>>> 
>>>>>> Delete the doc ...
>>>>>> $ curl -X "DELETE"
>>>>>> "http://localhost:15984/test/foo?rev=3-825cb35de44c433bfb2df415563a19de"{"ok":true,"id":"foo","rev":"4-1df13287548620bf858cf9d1b810972a"}
>>>>>> 
>>>>>> Update using an old rev, changing something ...
>>>>>> $ curl -X "PUT" -d '{"_id": "foo", "_rev":
>>>>>> "1-967a00dff5e02add41819138abb3284d", "num": 1}'
>>>>>> http://localhost:15984/test/foo
>>>>>> {"ok":true,"id":"foo","rev":"2-65371ad05fc99a9b794f68c6003bc8da"}
>>>>>> 
>>>>>> Now, I can sort of understand how something like that might happen
>>>>>> during replication but there's no replication going on here and
>>>>>> there's no conflict created in the database.
>>>>>> 
>>>>>> I can't think of a way around the problem at the moment, other than
>>>>>> marking the document for deletion and then sweeping it later when
>>>>>> something else is hopefully not going to be touching the document.
>>>>>> But, frankly, that's horrible,
>>>>>> 
>>>>>> - Matt
>>> 
>>> Hi Matt, bizarre.  Your latest email shows the behavior I expect -- you tried
to PUT a document using an incorrect MVCC revision, and you got a conflict as a result.  A
successful PUT of a new document with an _id that corresponds to a previously deleted document
should omit the MVCC rev.
>> 
>> Yep, I only posted that (it's what I would expect too) to demonstrate
>> how weird the problem is.
>> 
>>> 
>>> Your first email is the weird one -- you supplied an old MVCC _rev, but changed
the body to something different than the body at the time the doc was deleted, and it worked.
 I can confirm this.  Can you file a JIRA ticket?  Best,
>> 
>> Exactly. If there's a rev then it should match the current rev of the
>> doc or fail.
>> 
>> I'll file a ticket tomorrow morning.
> 
> There's a ticket for it already actually,
> https://issues.apache.org/jira/browse/COUCHDB-292. The ticket also
> contains a still failing test.
> 
> - Matt

A test submitted by you over 6 months ago, no less!  I need to spend more time looking at
the JIRA backlog.  Thanks,

Adam


Mime
View raw message