You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Stefan Kögl <ko...@gmail.com> on 2012/03/02 13:25:54 UTC
Update Conflict for PUT/DELETE in _replicator
Hi,
Again something I noticed during my 1.2.x experiments: It seems I
can't update or remove a document from the _replicator database, which
I use for pull-replication into my 1.2.x instance.
# get current _rev
$ curl http://127.0.0.1:5984/_replicator/mygpo
{"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
# try to delete
$ curl -X DELETE
"http://127.0.0.1:5984/_replicator/mygpo?_rev=131-57b4da8d3163468cb0bbf4fd30c87832"
{"error":"conflict","reason":"Document update conflict."}
# try to update
$ cat replication.json
{
"_id": "mygpo",
"_rev": "131-57b4da8d3163468cb0bbf4fd30c87832",
"_deleted": true,
"source": "************************",
"target": "http://stefan:********@127.0.0.1:5984/mygpo",
"create_target": false,
"continuous": true,
"user_ctx": {
"name": "stefan",
"roles": ["admin"]
}
}
$ curl -X PUT "http://127.0.0.1:5984/_replicator/mygpo" -d @replication.json
{"error":"conflict","reason":"Document update conflict."}
# check if rev has been updated in the meantime (but it hasn't)
$ curl http://127.0.0.1:5984/_replicator/mygpo
{"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
Did I just spot a bug or am I simply doing something wrong? I tried to
find any clues in [1], which seems to be a semi-official
documentation, but without luck.
-- Stefan
[1] https://gist.github.com/832610
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Stefan Kögl <ko...@gmail.com>.
On Mon, Mar 12, 2012 at 2:20 PM, Robert Newson <rn...@apache.org> wrote:
> I'd welcome a chance to access this database. couchdb admin level
> access is sufficient for now, email me directly at rnewson@apache.org.
For general information: The problem spontaneously disappeared when I
tried to reproduce it with the admin I created for rnewson... I'll
report back in case it happens again.
-- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Robert Newson <rn...@apache.org>.
Stefan,
I'd welcome a chance to access this database. couchdb admin level
access is sufficient for now, email me directly at rnewson@apache.org.
B.
On 12 March 2012 13:09, Stefan Kögl <ko...@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 2:01 PM, Jason Smith <jh...@iriscouch.com> wrote:
>> On Mon, Mar 12, 2012 at 12:57 PM, Stefan Kögl <ko...@gmail.com> wrote:
>>> In the meantime I tried copying the _replicator database to another
>>> instance, where I could delete the entry without problems. However it
>>> still doesn't work on the initial instance. If one of the committers
>>> is interested, I could organize either remote access via HTTP, or
>>> shell access to the machine it is running on.
>>
>> Hm, if you copied the _replicator.couch file from the 1.2.x prerelease
>> to version 1.1 then it will not support the newer file format.
>>
>> You could replicate to it, or since replication docs have no
>> attachments, just query _all_docs, massage that into a _bulk_docs, and
>> post it to the other couch.
>
> That's not the problem. I copied the database to another 1.2.x
> CouchDB, which could read and update it correctly.
> The problem is the original 1.2.x instance (both are on the current
> 1.2.x branch, btw) where I created the entry but can not update /
> delete it anymore.
>
> -- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Stefan Kögl <ko...@gmail.com>.
On Mon, Mar 12, 2012 at 2:01 PM, Jason Smith <jh...@iriscouch.com> wrote:
> On Mon, Mar 12, 2012 at 12:57 PM, Stefan Kögl <ko...@gmail.com> wrote:
>> In the meantime I tried copying the _replicator database to another
>> instance, where I could delete the entry without problems. However it
>> still doesn't work on the initial instance. If one of the committers
>> is interested, I could organize either remote access via HTTP, or
>> shell access to the machine it is running on.
>
> Hm, if you copied the _replicator.couch file from the 1.2.x prerelease
> to version 1.1 then it will not support the newer file format.
>
> You could replicate to it, or since replication docs have no
> attachments, just query _all_docs, massage that into a _bulk_docs, and
> post it to the other couch.
That's not the problem. I copied the database to another 1.2.x
CouchDB, which could read and update it correctly.
The problem is the original 1.2.x instance (both are on the current
1.2.x branch, btw) where I created the entry but can not update /
delete it anymore.
-- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Jason Smith <jh...@iriscouch.com>.
On Mon, Mar 12, 2012 at 12:57 PM, Stefan Kögl <ko...@gmail.com> wrote:
> In the meantime I tried copying the _replicator database to another
> instance, where I could delete the entry without problems. However it
> still doesn't work on the initial instance. If one of the committers
> is interested, I could organize either remote access via HTTP, or
> shell access to the machine it is running on.
Hm, if you copied the _replicator.couch file from the 1.2.x prerelease
to version 1.1 then it will not support the newer file format.
You could replicate to it, or since replication docs have no
attachments, just query _all_docs, massage that into a _bulk_docs, and
post it to the other couch.
--
Iris Couch
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Stefan Kögl <ko...@gmail.com>.
In the meantime I tried copying the _replicator database to another
instance, where I could delete the entry without problems. However it
still doesn't work on the initial instance. If one of the committers
is interested, I could organize either remote access via HTTP, or
shell access to the machine it is running on.
-- Stefan
On Fri, Mar 2, 2012 at 4:30 PM, Stefan Kögl <ko...@gmail.com> wrote:
> On Fri, Mar 2, 2012 at 4:06 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> I just created a replication doc under 1.1.1 and then copied the
>> _replicator.couch file to a 1.2.x. On update I the expected result
>> Robert also got ("Only the replicator can edit replication documents
>> that are in the triggered state.". a curl -X DELETE on the doc with
>> ?rev=4-abcd... (no quotes) also worked.
>
> The document was created with 1.2.x, from around the time of the second RC.
>
> I also tried with quotes and got
>
> $ curl -sv -X DELETE
> "http://stefan:*********@127.0.0.1:5984/_replicator/mygpo?rev=\"131-57b4da8d3163468cb0bbf4fd30c87832\""
> * About to connect() to 127.0.0.1 port 5984 (#0)
> * Trying 127.0.0.1... connected
> * Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
> * Server auth using Basic with user 'stefan'
>> DELETE /_replicator/mygpo?rev="131-57b4da8d3163468cb0bbf4fd30c87832" HTTP/1.1
>> Authorization: Basic **************************
>> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
>> Host: 127.0.0.1:5984
>> Accept: */*
>>
> < HTTP/1.1 500 Internal Server Error
> < Server: CouchDB/1.2.0 (Erlang OTP/R14B04)
> < Date: Fri, 02 Mar 2012 15:18:31 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 44
> < Cache-Control: must-revalidate
> <
> {"error":"unknown_error","reason":"badarg"}
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
>
> After that I also tried compacting the _replicator database, but also
> that didn't change anything.
>
>
> -- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Stefan Kögl <ko...@gmail.com>.
On Fri, Mar 2, 2012 at 4:06 PM, Jan Lehnardt <ja...@apache.org> wrote:
> I just created a replication doc under 1.1.1 and then copied the
> _replicator.couch file to a 1.2.x. On update I the expected result
> Robert also got ("Only the replicator can edit replication documents
> that are in the triggered state.". a curl -X DELETE on the doc with
> ?rev=4-abcd... (no quotes) also worked.
The document was created with 1.2.x, from around the time of the second RC.
I also tried with quotes and got
$ curl -sv -X DELETE
"http://stefan:*********@127.0.0.1:5984/_replicator/mygpo?rev=\"131-57b4da8d3163468cb0bbf4fd30c87832\""
* About to connect() to 127.0.0.1 port 5984 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
* Server auth using Basic with user 'stefan'
> DELETE /_replicator/mygpo?rev="131-57b4da8d3163468cb0bbf4fd30c87832" HTTP/1.1
> Authorization: Basic **************************
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: 127.0.0.1:5984
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Server: CouchDB/1.2.0 (Erlang OTP/R14B04)
< Date: Fri, 02 Mar 2012 15:18:31 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 44
< Cache-Control: must-revalidate
<
{"error":"unknown_error","reason":"badarg"}
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
After that I also tried compacting the _replicator database, but also
that didn't change anything.
-- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Jan Lehnardt <ja...@apache.org>.
I just created a replication doc under 1.1.1 and then copied the
_replicator.couch file to a 1.2.x. On update I the expected result
Robert also got ("Only the replicator can edit replication documents
that are in the triggered state.". a curl -X DELETE on the doc with
?rev=4-abcd... (no quotes) also worked.
Cheers
Jan
--
On Mar 2, 2012, at 15:34 , Robert Newson wrote:
> yes, you should be able to delete it (I can, locally). Running out of
> ideas but could you try double quotes around the rev? i.e,
> ?rev="131-57b4da8d3163468cb0bbf4fd30c87832"
>
> B.
>
> On 2 March 2012 14:32, Jan Lehnardt <ja...@apache.org> wrote:
>> Was the replication doc created in a 1.1.x CouchDB?
>>
>> Cheers
>> Jan
>> --
>>
>> On Mar 2, 2012, at 14:58 , Stefan Kögl wrote:
>>
>>> On Fri, Mar 2, 2012 at 2:54 PM, Robert Newson <rn...@apache.org> wrote:
>>>> could you redo the DELETE or PUT with '-sv' so we can see what's
>>>> really being sent? Perhaps there's a weird shell thing happening
>>>> causing the rev to be sent incorrectly.
>>>
>>>
>>> $ curl -sv -X DELETE
>>> "http://stefan:*********@127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832"
>>> * About to connect() to 127.0.0.1 port 5984 (#0)
>>> * Trying 127.0.0.1... connected
>>> * Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
>>> * Server auth using Basic with user 'stefan'
>>>> DELETE /_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832 HTTP/1.1
>>>> Authorization: Basic **********************
>>>> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
>>>> Host: 127.0.0.1:5984
>>>> Accept: */*
>>>>
>>> < HTTP/1.1 409 Conflict
>>> < Server: CouchDB/1.2.0 (Erlang OTP/R14B04)
>>> < Date: Fri, 02 Mar 2012 13:57:01 GMT
>>> < Content-Type: text/plain; charset=utf-8
>>> < Content-Length: 58
>>> < Cache-Control: must-revalidate
>>> <
>>> {"error":"conflict","reason":"Document update conflict."}
>>> * Connection #0 to host 127.0.0.1 left intact
>>> * Closing connection #0
>>>
>>> I verified the rev before and after the DELETE to make sure it hasn't
>>> changed in between.
>>>
>>>
>>>> On 2 March 2012 13:51, Robert Newson <rn...@apache.org> wrote:
>>>>> tbh you should be getting this error: 'Only the replicator can edit
>>>>> replication documents that are in the triggered state'. I do.
>>>
>>> Shouldn't I be able to DELETE the replication document?
>>>
>>>
>>> -- Stefan
>>
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Robert Newson <rn...@apache.org>.
yes, you should be able to delete it (I can, locally). Running out of
ideas but could you try double quotes around the rev? i.e,
?rev="131-57b4da8d3163468cb0bbf4fd30c87832"
B.
On 2 March 2012 14:32, Jan Lehnardt <ja...@apache.org> wrote:
> Was the replication doc created in a 1.1.x CouchDB?
>
> Cheers
> Jan
> --
>
> On Mar 2, 2012, at 14:58 , Stefan Kögl wrote:
>
>> On Fri, Mar 2, 2012 at 2:54 PM, Robert Newson <rn...@apache.org> wrote:
>>> could you redo the DELETE or PUT with '-sv' so we can see what's
>>> really being sent? Perhaps there's a weird shell thing happening
>>> causing the rev to be sent incorrectly.
>>
>>
>> $ curl -sv -X DELETE
>> "http://stefan:*********@127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832"
>> * About to connect() to 127.0.0.1 port 5984 (#0)
>> * Trying 127.0.0.1... connected
>> * Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
>> * Server auth using Basic with user 'stefan'
>>> DELETE /_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832 HTTP/1.1
>>> Authorization: Basic **********************
>>> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
>>> Host: 127.0.0.1:5984
>>> Accept: */*
>>>
>> < HTTP/1.1 409 Conflict
>> < Server: CouchDB/1.2.0 (Erlang OTP/R14B04)
>> < Date: Fri, 02 Mar 2012 13:57:01 GMT
>> < Content-Type: text/plain; charset=utf-8
>> < Content-Length: 58
>> < Cache-Control: must-revalidate
>> <
>> {"error":"conflict","reason":"Document update conflict."}
>> * Connection #0 to host 127.0.0.1 left intact
>> * Closing connection #0
>>
>> I verified the rev before and after the DELETE to make sure it hasn't
>> changed in between.
>>
>>
>>> On 2 March 2012 13:51, Robert Newson <rn...@apache.org> wrote:
>>>> tbh you should be getting this error: 'Only the replicator can edit
>>>> replication documents that are in the triggered state'. I do.
>>
>> Shouldn't I be able to DELETE the replication document?
>>
>>
>> -- Stefan
>
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Jan Lehnardt <ja...@apache.org>.
Was the replication doc created in a 1.1.x CouchDB?
Cheers
Jan
--
On Mar 2, 2012, at 14:58 , Stefan Kögl wrote:
> On Fri, Mar 2, 2012 at 2:54 PM, Robert Newson <rn...@apache.org> wrote:
>> could you redo the DELETE or PUT with '-sv' so we can see what's
>> really being sent? Perhaps there's a weird shell thing happening
>> causing the rev to be sent incorrectly.
>
>
> $ curl -sv -X DELETE
> "http://stefan:*********@127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832"
> * About to connect() to 127.0.0.1 port 5984 (#0)
> * Trying 127.0.0.1... connected
> * Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
> * Server auth using Basic with user 'stefan'
>> DELETE /_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832 HTTP/1.1
>> Authorization: Basic **********************
>> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
>> Host: 127.0.0.1:5984
>> Accept: */*
>>
> < HTTP/1.1 409 Conflict
> < Server: CouchDB/1.2.0 (Erlang OTP/R14B04)
> < Date: Fri, 02 Mar 2012 13:57:01 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 58
> < Cache-Control: must-revalidate
> <
> {"error":"conflict","reason":"Document update conflict."}
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
>
> I verified the rev before and after the DELETE to make sure it hasn't
> changed in between.
>
>
>> On 2 March 2012 13:51, Robert Newson <rn...@apache.org> wrote:
>>> tbh you should be getting this error: 'Only the replicator can edit
>>> replication documents that are in the triggered state'. I do.
>
> Shouldn't I be able to DELETE the replication document?
>
>
> -- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Stefan Kögl <ko...@gmail.com>.
On Fri, Mar 2, 2012 at 2:54 PM, Robert Newson <rn...@apache.org> wrote:
> could you redo the DELETE or PUT with '-sv' so we can see what's
> really being sent? Perhaps there's a weird shell thing happening
> causing the rev to be sent incorrectly.
$ curl -sv -X DELETE
"http://stefan:*********@127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832"
* About to connect() to 127.0.0.1 port 5984 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
* Server auth using Basic with user 'stefan'
> DELETE /_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832 HTTP/1.1
> Authorization: Basic **********************
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: 127.0.0.1:5984
> Accept: */*
>
< HTTP/1.1 409 Conflict
< Server: CouchDB/1.2.0 (Erlang OTP/R14B04)
< Date: Fri, 02 Mar 2012 13:57:01 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 58
< Cache-Control: must-revalidate
<
{"error":"conflict","reason":"Document update conflict."}
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
I verified the rev before and after the DELETE to make sure it hasn't
changed in between.
> On 2 March 2012 13:51, Robert Newson <rn...@apache.org> wrote:
>> tbh you should be getting this error: 'Only the replicator can edit
>> replication documents that are in the triggered state'. I do.
Shouldn't I be able to DELETE the replication document?
-- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Robert Newson <rn...@apache.org>.
could you redo the DELETE or PUT with '-sv' so we can see what's
really being sent? Perhaps there's a weird shell thing happening
causing the rev to be sent incorrectly.
On 2 March 2012 13:51, Robert Newson <rn...@apache.org> wrote:
> tbh you should be getting this error: 'Only the replicator can edit
> replication documents that are in the triggered state'. I do.
>
> B.
>
>
> On 2 March 2012 13:38, Stefan Kögl <ko...@gmail.com> wrote:
>> On Fri, Mar 2, 2012 at 2:21 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>> can you try http://stefan:youpassword@127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832
>>> ^^^^^^^^^^^^^^^^^^^ - note the auth info
>>>
>>> Same with the PUT.
>>>
>>> This is something that has changed in 1.2.x: http://wiki.apache.org/couchdb/Breaking_changes#Changes_Between_1.1.0_and_1.2.0
>>>
>>> If that's it though, I'd argue the error message could be improved.
>>
>> Didn't change anything, unfortunately. Same result for both DELETE and PUT.
>>
>> Interestingly, when I first tried to delete the document (maybe 2 days
>> ago) I got the same error message, and the rev was 121-<hash>. I
>> didn't succeed and tried again today, when the rev was at
>> 131-<somehash>. So it seems that the replication can update the
>> document, but I can't. Also the error message is a different one when
>> I try with incorrect credentials.
>>
>>
>> -- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Robert Newson <rn...@apache.org>.
tbh you should be getting this error: 'Only the replicator can edit
replication documents that are in the triggered state'. I do.
B.
On 2 March 2012 13:38, Stefan Kögl <ko...@gmail.com> wrote:
> On Fri, Mar 2, 2012 at 2:21 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> can you try http://stefan:youpassword@127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832
>> ^^^^^^^^^^^^^^^^^^^ - note the auth info
>>
>> Same with the PUT.
>>
>> This is something that has changed in 1.2.x: http://wiki.apache.org/couchdb/Breaking_changes#Changes_Between_1.1.0_and_1.2.0
>>
>> If that's it though, I'd argue the error message could be improved.
>
> Didn't change anything, unfortunately. Same result for both DELETE and PUT.
>
> Interestingly, when I first tried to delete the document (maybe 2 days
> ago) I got the same error message, and the rev was 121-<hash>. I
> didn't succeed and tried again today, when the rev was at
> 131-<somehash>. So it seems that the replication can update the
> document, but I can't. Also the error message is a different one when
> I try with incorrect credentials.
>
>
> -- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Stefan Kögl <ko...@gmail.com>.
On Fri, Mar 2, 2012 at 2:21 PM, Jan Lehnardt <ja...@apache.org> wrote:
> can you try http://stefan:youpassword@127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832
> ^^^^^^^^^^^^^^^^^^^ - note the auth info
>
> Same with the PUT.
>
> This is something that has changed in 1.2.x: http://wiki.apache.org/couchdb/Breaking_changes#Changes_Between_1.1.0_and_1.2.0
>
> If that's it though, I'd argue the error message could be improved.
Didn't change anything, unfortunately. Same result for both DELETE and PUT.
Interestingly, when I first tried to delete the document (maybe 2 days
ago) I got the same error message, and the rev was 121-<hash>. I
didn't succeed and tried again today, when the rev was at
131-<somehash>. So it seems that the replication can update the
document, but I can't. Also the error message is a different one when
I try with incorrect credentials.
-- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Jan Lehnardt <ja...@apache.org>.
On Mar 2, 2012, at 14:11 , Stefan Kögl wrote:
> On Fri, Mar 2, 2012 at 1:39 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> On Mar 2, 2012, at 13:25 , Stefan Kögl wrote:
>>> Again something I noticed during my 1.2.x experiments: It seems I
>>> can't update or remove a document from the _replicator database, which
>>> I use for pull-replication into my 1.2.x instance.
>>>
>>> # get current _rev
>>> $ curl http://127.0.0.1:5984/_replicator/mygpo
>>> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>>>
>>> # try to delete
>>> $ curl -X DELETE
>>> "http://127.0.0.1:5984/_replicator/mygpo?_rev=131-57b4da8d3163468cb0bbf4fd30c87832"
>>> {"error":"conflict","reason":"Document update conflict."}
>>
>> this should be ?rev=... (no underscore)
>
> Of course, I also tried that but it didn't work either... see below.
Cool, next step, see below :)
>>> $ curl -X PUT "http://127.0.0.1:5984/_replicator/mygpo" -d @replication.json
>>
>> Can you try adding the ?rev= in the URL as well?
>
> # get the rev first
> $ curl http://127.0.0.1:5984/_replicator/mygpo
> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"********************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>
> # delete with rev instead of _rev
> $ curl -X DELETE
> "http://127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832"
can you try http://stefan:youpassword@127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832
^^^^^^^^^^^^^^^^^^^ - note the auth info
Same with the PUT.
This is something that has changed in 1.2.x: http://wiki.apache.org/couchdb/Breaking_changes#Changes_Between_1.1.0_and_1.2.0
If that's it though, I'd argue the error message could be improved.
Cheers
Jan
--
> {"error":"conflict","reason":"Document update conflict."}
>
> # now PUT with rev in URL
> $ curl -X PUT "http://127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832"
> -d @replication.json
> {"error":"conflict","reason":"Document update conflict."}
>
> # still the same rev (no other change in between)
> $ curl http://127.0.0.1:5984/_replicator/mygpo
> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"********************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>
>
> -- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Stefan Kögl <ko...@gmail.com>.
On Fri, Mar 2, 2012 at 1:39 PM, Jan Lehnardt <ja...@apache.org> wrote:
> On Mar 2, 2012, at 13:25 , Stefan Kögl wrote:
>> Again something I noticed during my 1.2.x experiments: It seems I
>> can't update or remove a document from the _replicator database, which
>> I use for pull-replication into my 1.2.x instance.
>>
>> # get current _rev
>> $ curl http://127.0.0.1:5984/_replicator/mygpo
>> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>>
>> # try to delete
>> $ curl -X DELETE
>> "http://127.0.0.1:5984/_replicator/mygpo?_rev=131-57b4da8d3163468cb0bbf4fd30c87832"
>> {"error":"conflict","reason":"Document update conflict."}
>
> this should be ?rev=... (no underscore)
Of course, I also tried that but it didn't work either... see below.
>> $ curl -X PUT "http://127.0.0.1:5984/_replicator/mygpo" -d @replication.json
>
> Can you try adding the ?rev= in the URL as well?
# get the rev first
$ curl http://127.0.0.1:5984/_replicator/mygpo
{"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"********************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
# delete with rev instead of _rev
$ curl -X DELETE
"http://127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832"
{"error":"conflict","reason":"Document update conflict."}
# now PUT with rev in URL
$ curl -X PUT "http://127.0.0.1:5984/_replicator/mygpo?rev=131-57b4da8d3163468cb0bbf4fd30c87832"
-d @replication.json
{"error":"conflict","reason":"Document update conflict."}
# still the same rev (no other change in between)
$ curl http://127.0.0.1:5984/_replicator/mygpo
{"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"********************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
-- Stefan
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Jan Lehnardt <ja...@apache.org>.
On Mar 2, 2012, at 13:25 , Stefan Kögl wrote:
> Hi,
>
> Again something I noticed during my 1.2.x experiments: It seems I
> can't update or remove a document from the _replicator database, which
> I use for pull-replication into my 1.2.x instance.
>
> # get current _rev
> $ curl http://127.0.0.1:5984/_replicator/mygpo
> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>
> # try to delete
> $ curl -X DELETE
> "http://127.0.0.1:5984/_replicator/mygpo?_rev=131-57b4da8d3163468cb0bbf4fd30c87832"
> {"error":"conflict","reason":"Document update conflict."}
this should be ?rev=... (no underscore)
> # try to update
> $ cat replication.json
> {
> "_id": "mygpo",
> "_rev": "131-57b4da8d3163468cb0bbf4fd30c87832",
> "_deleted": true,
> "source": "************************",
> "target": "http://stefan:********@127.0.0.1:5984/mygpo",
> "create_target": false,
> "continuous": true,
> "user_ctx": {
> "name": "stefan",
> "roles": ["admin"]
> }
> }
>
> $ curl -X PUT "http://127.0.0.1:5984/_replicator/mygpo" -d @replication.json
Can you try adding the ?rev= in the URL as well?
Cheers
Jan
--
> {"error":"conflict","reason":"Document update conflict."}
>
> # check if rev has been updated in the meantime (but it hasn't)
> $ curl http://127.0.0.1:5984/_replicator/mygpo
> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>
>
> Did I just spot a bug or am I simply doing something wrong? I tried to
> find any clues in [1], which seems to be a semi-official
> documentation, but without luck.
>
>
> -- Stefan
>
>
> [1] https://gist.github.com/832610
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Robert Newson <rn...@apache.org>.
also I think it's ?rev= not ?_rev=
On 2 March 2012 12:34, Robert Newson <rn...@apache.org> wrote:
> The document is updated periodically, I expect you just had the wrong _rev?
>
> On 2 March 2012 12:25, Stefan Kögl <ko...@gmail.com> wrote:
>> Hi,
>>
>> Again something I noticed during my 1.2.x experiments: It seems I
>> can't update or remove a document from the _replicator database, which
>> I use for pull-replication into my 1.2.x instance.
>>
>> # get current _rev
>> $ curl http://127.0.0.1:5984/_replicator/mygpo
>> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>>
>> # try to delete
>> $ curl -X DELETE
>> "http://127.0.0.1:5984/_replicator/mygpo?_rev=131-57b4da8d3163468cb0bbf4fd30c87832"
>> {"error":"conflict","reason":"Document update conflict."}
>>
>> # try to update
>> $ cat replication.json
>> {
>> "_id": "mygpo",
>> "_rev": "131-57b4da8d3163468cb0bbf4fd30c87832",
>> "_deleted": true,
>> "source": "************************",
>> "target": "http://stefan:********@127.0.0.1:5984/mygpo",
>> "create_target": false,
>> "continuous": true,
>> "user_ctx": {
>> "name": "stefan",
>> "roles": ["admin"]
>> }
>> }
>>
>> $ curl -X PUT "http://127.0.0.1:5984/_replicator/mygpo" -d @replication.json
>> {"error":"conflict","reason":"Document update conflict."}
>>
>> # check if rev has been updated in the meantime (but it hasn't)
>> $ curl http://127.0.0.1:5984/_replicator/mygpo
>> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>>
>>
>> Did I just spot a bug or am I simply doing something wrong? I tried to
>> find any clues in [1], which seems to be a semi-official
>> documentation, but without luck.
>>
>>
>> -- Stefan
>>
>>
>> [1] https://gist.github.com/832610
Re: Update Conflict for PUT/DELETE in _replicator
Posted by Robert Newson <rn...@apache.org>.
The document is updated periodically, I expect you just had the wrong _rev?
On 2 March 2012 12:25, Stefan Kögl <ko...@gmail.com> wrote:
> Hi,
>
> Again something I noticed during my 1.2.x experiments: It seems I
> can't update or remove a document from the _replicator database, which
> I use for pull-replication into my 1.2.x instance.
>
> # get current _rev
> $ curl http://127.0.0.1:5984/_replicator/mygpo
> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>
> # try to delete
> $ curl -X DELETE
> "http://127.0.0.1:5984/_replicator/mygpo?_rev=131-57b4da8d3163468cb0bbf4fd30c87832"
> {"error":"conflict","reason":"Document update conflict."}
>
> # try to update
> $ cat replication.json
> {
> "_id": "mygpo",
> "_rev": "131-57b4da8d3163468cb0bbf4fd30c87832",
> "_deleted": true,
> "source": "************************",
> "target": "http://stefan:********@127.0.0.1:5984/mygpo",
> "create_target": false,
> "continuous": true,
> "user_ctx": {
> "name": "stefan",
> "roles": ["admin"]
> }
> }
>
> $ curl -X PUT "http://127.0.0.1:5984/_replicator/mygpo" -d @replication.json
> {"error":"conflict","reason":"Document update conflict."}
>
> # check if rev has been updated in the meantime (but it hasn't)
> $ curl http://127.0.0.1:5984/_replicator/mygpo
> {"_id":"mygpo","_rev":"131-57b4da8d3163468cb0bbf4fd30c87832","source":"************************","target":"http://127.0.0.1:5984/mygpo","create_target":false,"continuous":true,"user_ctx":{"name":"stefan","roles":["admin"]},"owner":"stefan","_replication_state":"triggered","_replication_state_time":"2012-03-02T02:56:12+00:00","_replication_id":"f9fc5457b278d3cdb1ba2f1881253b04"}
>
>
> Did I just spot a bug or am I simply doing something wrong? I tried to
> find any clues in [1], which seems to be a semi-official
> documentation, but without luck.
>
>
> -- Stefan
>
>
> [1] https://gist.github.com/832610