You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Mark Hahn <ma...@boutiquing.com> on 2011/09/01 00:33:36 UTC

Re: url rev=x overwrite document _rev:y

I guess I don't understand.  All I can say is that in general you
cannot change the _rev of a doc.  The rev includes a hash of the doc.

If you want to make sure you don't get a conflict, then you will need
to first GET the old doc and use the _rev of that old doc.  I do that
in a loop doing a PUT over and over until I get no conflict.  Of
course it usually works on the first PUT and no GET is needed.

On Wed, Aug 31, 2011 at 2:50 PM, Gert Cuykens <ge...@gmail.com> wrote:
> The app does not need to change the rev in the database, just the _rev
> that is in the PUT or POST data which is about to get send too the
> database. It already happens when adding attachments to couchdb
> preventing conflicts. It is only logic it does this for normal updates
> too when specified explicit in the url ignoring the _rev in the POST
> or PUT data.
>
> Now I need to parse the json files one by one to change the _rev
> inside the documents that need to get send.
>
> On Wed, Aug 31, 2011 at 9:00 PM, Mark Hahn <ma...@boutiquing.com> wrote:
>> The rev is used for replication.  If the app could change a rev,
>> replication would break.
>>
>> On Wed, Aug 31, 2011 at 9:53 AM, Gert Cuykens <ge...@gmail.com> wrote:
>>> I believe that PUT http://localhost:5984/db/mydoc?rev=1-x -d
>>> @newdoc.json should overwrite the _rev in the newdoc.json? Can you
>>> point me too the discussion why this has not been done pleas.
>>>
>>
>

Re: url rev=x overwrite document _rev:y

Posted by Gert Cuykens <ge...@gmail.com>.
On Thu, Sep 1, 2011 at 1:22 AM, Jens Alfke <je...@couchbase.com> wrote:
>
> On Aug 31, 2011, at 4:17 PM, Gert Cuykens wrote:
>
> Yes, exactly it will tremendously improve and shorten my client code.
>
> Tremendously? I ran into this issue as well when writing my own client library [CouchCocoa] but it was pretty easy to work around by simply inserting a _rev key into the JSON before writing it into the HTTP request. I think it added three or four lines of Objective-C code to my method that saves documents.
>
> Can you implement this in the development branch pleas.
>
> Sorry, I don’t work on the implementation of CouchDB itself. You should file a bug/enhancement request.
>
> —Jens
>

I also suggest _id get replaced by the url too, but that is currently
happening already as far as I can test. I strongly believe json bodies
like this should never contain _id's and _rev's
I will try to submit this at
https://issues.apache.org/jira/browse/COUCHDB thanks. Never the less
the same should also apply too couchbase :)

Re: url rev=x overwrite document _rev:y

Posted by Gert Cuykens <ge...@gmail.com>.
On Thu, Sep 1, 2011 at 1:22 AM, Jens Alfke <je...@couchbase.com> wrote:
> On Aug 31, 2011, at 4:17 PM, Gert Cuykens wrote:
>
> Yes, exactly it will tremendously improve and shorten my client code.
>
> Tremendously? I ran into this issue as well when writing my own client library [CouchCocoa] but it was pretty easy to work around by simply inserting a _rev key into the JSON before writing it into the HTTP request. I think it added three or four lines of Objective-C code to my method that saves documents.

When my client shell script is only 8 lines, 4 extra lines is a 50% increase :P

> Can you implement this in the development branch pleas.
>
> Sorry, I don’t work on the implementation of CouchDB itself. You should file a bug/enhancement request.
>

https://issues.apache.org/jira/browse/COUCHDB-1268

Re: url rev=x overwrite document _rev:y

Posted by Jens Alfke <je...@couchbase.com>.
On Aug 31, 2011, at 4:17 PM, Gert Cuykens wrote:

Yes, exactly it will tremendously improve and shorten my client code.

Tremendously? I ran into this issue as well when writing my own client library [CouchCocoa] but it was pretty easy to work around by simply inserting a _rev key into the JSON before writing it into the HTTP request. I think it added three or four lines of Objective-C code to my method that saves documents.

Can you implement this in the development branch pleas.

Sorry, I don’t work on the implementation of CouchDB itself. You should file a bug/enhancement request.

—Jens

Re: url rev=x overwrite document _rev:y

Posted by Gert Cuykens <ge...@gmail.com>.
On Thu, Sep 1, 2011 at 1:12 AM, Jens Alfke <je...@couchbase.com> wrote:
>
> On Aug 31, 2011, at 4:00 PM, Gert Cuykens wrote:
>
>> The first example, will result into a document conflict because rev is
>> not specified in the doc and the rev from the the url gets ignored.
>> All other examples work
>
> I think what you’re pointing out is that when PUTting a document you have to specify the current revision as a _rev key in the JSON; whereas many related requests (like DELETE, COPY and PUT of an attachment) specify the revision in a “?rev=“ URL query parameter instead.
>
> I _think_ the reason for this is that PUT came first and has the simplicity of requiring that you send back a modified copy of the exact document you got from the GET. When the other requests were added they didn’t have any obvious JSON body to hold the _rev, so they added it to the URL instead.
>
> It seems reasonable to suggest that PUT be allowed to specify the revision ID in the URL as an option. It might simplify some client’s code if it were consistent with the other requests that modify documents.
>
> —Jens

Yes, exactly it will tremendously improve and shorten my client code.
Can you implement this in the development branch pleas.

Re: url rev=x overwrite document _rev:y

Posted by Jens Alfke <je...@couchbase.com>.
On Aug 31, 2011, at 4:00 PM, Gert Cuykens wrote:

> The first example, will result into a document conflict because rev is
> not specified in the doc and the rev from the the url gets ignored.
> All other examples work

I think what you’re pointing out is that when PUTting a document you have to specify the current revision as a _rev key in the JSON; whereas many related requests (like DELETE, COPY and PUT of an attachment) specify the revision in a “?rev=“ URL query parameter instead.

I _think_ the reason for this is that PUT came first and has the simplicity of requiring that you send back a modified copy of the exact document you got from the GET. When the other requests were added they didn’t have any obvious JSON body to hold the _rev, so they added it to the URL instead.

It seems reasonable to suggest that PUT be allowed to specify the revision ID in the URL as an option. It might simplify some client’s code if it were consistent with the other requests that modify documents.

—Jens

Re: url rev=x overwrite document _rev:y

Posted by Gert Cuykens <ge...@gmail.com>.
The first example, will result into a document conflict because rev is
not specified in the doc and the rev from the the url gets ignored.
All other examples work. Note that the last example is a picture
attachment that also does not contain a rev inside a binary file, why
can this not be applied to json data too like in the first example.

curl -X PUT http://localhost:5984/_users/user%3Agert?rev=5xxx -H
'Content-Type: application/json' -d{
  "_id"          : "user:gert",
  "type"         : "user",
  "name"         : "gert",
  "roles"        : [],
  "password_sha" : "",
  "salt"         : ""
}'

curl -X PUT http://localhost:5984/_users/user%3Agert -H 'Content-Type:
application/json' -d{
  "_id"          : "user:gert",
  "_rev":"5xxx",
  "type"         : "user",
  "name"         : "gert",
  "roles"        : [],
  "password_sha" : "",
  "salt"         : ""
}'

curl -X PUT http://localhost:5984/_users/user%3Agert/picture?rev=5xxx
-H 'Content-Type: image/png' -d @picture.png

On Thu, Sep 1, 2011 at 12:33 AM, Mark Hahn <ma...@boutiquing.com> wrote:
> I guess I don't understand.  All I can say is that in general you
> cannot change the _rev of a doc.  The rev includes a hash of the doc.
>
> If you want to make sure you don't get a conflict, then you will need
> to first GET the old doc and use the _rev of that old doc.  I do that
> in a loop doing a PUT over and over until I get no conflict.  Of
> course it usually works on the first PUT and no GET is needed.
>
> On Wed, Aug 31, 2011 at 2:50 PM, Gert Cuykens <ge...@gmail.com> wrote:
>> The app does not need to change the rev in the database, just the _rev
>> that is in the PUT or POST data which is about to get send too the
>> database. It already happens when adding attachments to couchdb
>> preventing conflicts. It is only logic it does this for normal updates
>> too when specified explicit in the url ignoring the _rev in the POST
>> or PUT data.
>>
>> Now I need to parse the json files one by one to change the _rev
>> inside the documents that need to get send.
>>
>> On Wed, Aug 31, 2011 at 9:00 PM, Mark Hahn <ma...@boutiquing.com> wrote:
>>> The rev is used for replication.  If the app could change a rev,
>>> replication would break.
>>>
>>> On Wed, Aug 31, 2011 at 9:53 AM, Gert Cuykens <ge...@gmail.com> wrote:
>>>> I believe that PUT http://localhost:5984/db/mydoc?rev=1-x -d
>>>> @newdoc.json should overwrite the _rev in the newdoc.json? Can you
>>>> point me too the discussion why this has not been done pleas.
>>>>
>>>
>>
>