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"}
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
