On Mon, Jan 24, 2011 at 4:16 PM, Martin Hilbig <[email protected]> wrote:
> hi,
>
> is this a known bug or even my fault?
>
> create db:
>
> curl -X PUT http://localhost:5984/fail
> {"ok":true}
>
> create doc:
>
> curl -vX PUT http://localhost:5984/fail/doc -d '{}'
> {"ok":true,"id":"doc","rev":"1-967a00dff5e02add41819138abb3284d"}
>
> put attachment with nearly correct format ?rev=x-y
>
> curl -vX PUT http://localhost:5984/fail/doc/att?rev=12-12345 -d '{}'
>> PUT /fail/doc/att?rev=12-12345 HTTP/1.1
>> User-Agent: curl/7.21.3 (x86_64-unknown-linux-gnu) libcurl/7.21.3
>> OpenSSL/1.0.0c zlib/1.2.5
>> Host: localhost:5984
>> Accept: */*
>> Content-Length: 2
>> Content-Type: application/x-www-form-urlencoded
>>
> < HTTP/1.1 500 Internal Server Error
> < Server: CouchDB/1.0.1 (Erlang OTP/R14B)
> < Date: Mon, 24 Jan 2011 21:08:53 GMT
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 62
> < Cache-Control: must-revalidate
> <
> {"error":"{not_found,missing}","reason":"{12,<<\"12345\">>}"}
>
> shouldn't look this like:
>
> curl -X PUT
> http://localhost:5984/fail/doc/att?rev=1-967a00dff5e02add41819138abb3284d -d
> '{}'
> {"ok":true,"id":"doc","rev":"2-25fb7eb27842ed11617f4e8656600c54"}
>
> curl -vX PUT
> http://localhost:5984/fail/doc/att?rev=1-967a00dff5e02add41819138abb3284d -d
> '{}'
>> PUT /fail/doc/att?rev=1-967a00dff5e02add41819138abb3284d HTTP/1.1
>> User-Agent: curl/7.21.3 (x86_64-unknown-linux-gnu) libcurl/7.21.3
>> OpenSSL/1.0.0c zlib/1.2.5
>> Host: localhost:5984
>> Accept: */*
>> Content-Length: 2
>> Content-Type: application/x-www-form-urlencoded
>>
> < HTTP/1.1 409 Conflict
> < Server: CouchDB/1.0.1 (Erlang OTP/R14B)
> < Date: Mon, 24 Jan 2011 21:12:04 GMT
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 58
> < Cache-Control: must-revalidate
> <
> {"error":"conflict","reason":"Document update conflict."}
>
> to sum it up: couchdb only sends a correct 'document update conflict' on
> attachments, when you give a rev already in the documents history.
>
> have fun
> martin
>
I think more likely its that 12-12345 fails to parse as a correct
revision and the error gets confused as it bubbles up the stack.
To verify, try replacing 12-12345 with a modified version of the
previous revision, ie, so it matches the (\d+)-([a-z0-9]{32}) regular
expression.
