put and no _rev

[aju <aj...@muly.dk>]

hi

[first post to this list]

either i am missing the obvious or otherwise this might be a feature 
request ;)

it would be convenient if one could PUT an existing document without 
supplying a _rev number.

the argument for supplying the _rev number appears to be so that couchDB 
can apply a it's diff mechanism based on that particular revision - much 
like a MVCC.

in case of a PUT where one doesn't supply the _rev number, couchDB 
should then just assume and use "last revision number" as a base (i 
guess "last" is known server side looking at Futon).

otherwise one have to first figure out which revision is latest (1. 
request) plus then update the document (2. request).

makes sense ?

thanks
./allan

Re: put and no _rev

[Chris Anderson <jc...@apache.org>]

On Fri, Mar 6, 2009 at 8:50 AM, aju <aj...@muly.dk> wrote:
> otherwise one have to first figure out which revision is latest (1. request)
> plus then update the document (2. request).
>

That's kinda the point. This is so "whoever saves first wins"


-- 
Chris Anderson
http://jchris.mfdz.com

Re: put and no _rev

[aju <aj...@muly.dk>]

thanks all

i guess my confusion stemmed from the fact that i hadn't read this 
fundamental sentence from the docs

"You cannot rely on document revisions for any other purpose than 
concurrency control."

./allan

Paul Davis wrote:

> Its a single step for the *user* in both cases. Both RDBMS's and
> Subversion are doing *alot* of behind the scenes voodoo to make sure
> that you're not overwriting a single doc simultaneous for consistency
> and transactional semantics. The issue is that when you try and make
> this magic span physical hosts it gets really hard.
> 
>> consider from the wiki docs:
>>
>>  GET /somedatabase/some_doc_id HTTP/1.0
>>
>>  "The above example gets the current revision"
>>
>>
>>
>> then why would
>>
>>
>>  PUT /somedatabase/some_doc_id HTTP/1.0
>>
>>
>> not also work on the current revision ?
>>
>>
>> ./allan
>>
> 
> And Jan just wrote my example.
> 
> Also for reference, the corresponding SQL is generally like such:
> 
> UPDATE ... WHERE docid = ? AND revision_identifier = ? ;
> if num_affected_rows != 1:
>     raise ConflictError()
> 
> HTH,
> Paul Davis
> 

Re: put and no _rev

[Paul Davis <pa...@gmail.com>]

On Fri, Mar 6, 2009 at 1:58 PM, aju <aj...@muly.dk> wrote:
> hi dean
>
> thank you for the reply.
>
> Dean Landolt wrote:
>
>> *Exactly *like MVCC. That's what the revs are for. There's no diff
>> mechanism
>> in couch.
>
> well, i guess couch do store the deltas.
>
>> If you mean do the two requests make sense, then yes. Or better yet, you
>> could just try to put, and if it fails, request the latest rev and give it
>> to your user to merge (or if you can do so algorithmically, then have at
>> it).
>
>
> what i hoped for was a solution with only one request for an action that
> should just "overwrite" the last document.
>
> in a RDBMS when you update an existing row (document) it is a single step.
> (there's no revision term here obviously). likewise in subversion when you
> commit an updated document it is a single step.
>

Its a single step for the *user* in both cases. Both RDBMS's and
Subversion are doing *alot* of behind the scenes voodoo to make sure
that you're not overwriting a single doc simultaneous for consistency
and transactional semantics. The issue is that when you try and make
this magic span physical hosts it gets really hard.

>
> consider from the wiki docs:
>
>  GET /somedatabase/some_doc_id HTTP/1.0
>
>  "The above example gets the current revision"
>
>
>
> then why would
>
>
>  PUT /somedatabase/some_doc_id HTTP/1.0
>
>
> not also work on the current revision ?
>
>
> ./allan
>

And Jan just wrote my example.

Also for reference, the corresponding SQL is generally like such:

UPDATE ... WHERE docid = ? AND revision_identifier = ? ;
if num_affected_rows != 1:
    raise ConflictError()

HTH,
Paul Davis

Re: put and no _rev

[Jan Lehnardt <ja...@apache.org>]

On 6 Mar 2009, at 20:24, aju wrote:

> Jason Smith wrote:
>> aju wrote:
>>> in a RDBMS when you update an existing row (document) it is a  
>>> single step. (there's no revision term here obviously). likewise  
>>> in subversion when you commit an updated document it is a single  
>>> step.
>> Well in a RDBMS if you have a common constraint like uniqueness on  
>> a column, you have to decide whether to INSERT or UPDATE.  So most  
>> likely, you will grab a big lock, SELECT something, process the  
>> data, INSERT or UPDATE, then release the lock.  So that's two  
>> queries as well.
>
> you are right. probably bad example, but i still can't see the  
> argument
> for not just updating a document based on the latest revision. how  
> can it hurt?
>
> hmm, or perhaps instead one could specify a special rev value "latest"
>
> 	PUT /somedatabase/some_doc_id?rev=latest
>

Imagine Wikipedia. You open a page for editing and sit down and write  
a nice and well-researched paragraph about your favourite band. A  
minute before you are done, I open the same page for editing, having  
the same base version that you have. Now you save your page and submit  
your work to Wikipedia. Then I save my changes to the version I know  
is previous, but doesn't include your changes. My change gets saved  
and yours is gone. Using _rev's I can't save my changes unless I get a  
newer version with your changes.

For the record: CouchDB does not store diffs.

Cheers
Jan
--

Re: put and no _rev

[aju <aj...@muly.dk>]

Jason Smith wrote:
> aju wrote:
>> in a RDBMS when you update an existing row (document) it is a single 
>> step. (there's no revision term here obviously). likewise in 
>> subversion when you commit an updated document it is a single step.
> 
> Well in a RDBMS if you have a common constraint like uniqueness on a 
> column, you have to decide whether to INSERT or UPDATE.  So most likely, 
> you will grab a big lock, SELECT something, process the data, INSERT or 
> UPDATE, then release the lock.  So that's two queries as well.
> 

you are right. probably bad example, but i still can't see the argument
for not just updating a document based on the latest revision. how can 
it hurt?

hmm, or perhaps instead one could specify a special rev value "latest"

	PUT /somedatabase/some_doc_id?rev=latest


./allan

Re: put and no _rev

[Jason Smith <jh...@proven-corporation.com>]

aju wrote:
> in a RDBMS when you update an existing row (document) it is a single 
> step. (there's no revision term here obviously). likewise in subversion 
> when you commit an updated document it is a single step.

Well in a RDBMS if you have a common constraint like uniqueness on a 
column, you have to decide whether to INSERT or UPDATE.  So most likely, 
you will grab a big lock, SELECT something, process the data, INSERT or 
UPDATE, then release the lock.  So that's two queries as well.

-- 
Jason Smith
Proven Corporation
Bangkok, Thailand
http://www.proven-corporation.com

Re: put and no _rev

[aju <aj...@muly.dk>]

hi dean

thank you for the reply.

Dean Landolt wrote:

> *Exactly *like MVCC. That's what the revs are for. There's no diff mechanism
> in couch.

well, i guess couch do store the deltas.

> If you mean do the two requests make sense, then yes. Or better yet, you
> could just try to put, and if it fails, request the latest rev and give it
> to your user to merge (or if you can do so algorithmically, then have at
> it).


what i hoped for was a solution with only one request for an action that 
      should just "overwrite" the last document.

in a RDBMS when you update an existing row (document) it is a single 
step. (there's no revision term here obviously). likewise in subversion 
when you commit an updated document it is a single step.


consider from the wiki docs:

  GET /somedatabase/some_doc_id HTTP/1.0

  "The above example gets the current revision"



then why would


  PUT /somedatabase/some_doc_id HTTP/1.0


not also work on the current revision ?


./allan

Re: put and no _rev

[Dean Landolt <de...@deanlandolt.com>]

On Fri, Mar 6, 2009 at 11:50 AM, aju <aj...@muly.dk> wrote:

> hi
>
> [first post to this list]
>
> either i am missing the obvious or otherwise this might be a feature
> request ;)
>
> it would be convenient if one could PUT an existing document without
> supplying a _rev number.
>
> the argument for supplying the _rev number appears to be so that couchDB
> can apply a it's diff mechanism based on that particular revision - much
> like a MVCC.


*Exactly *like MVCC. That's what the revs are for. There's no diff mechanism
in couch.

>
>
> in case of a PUT where one doesn't supply the _rev number, couchDB should
> then just assume and use "last revision number" as a base (i guess "last" is
> known server side looking at Futon).
>
> otherwise one have to first figure out which revision is latest (1.
> request) plus then update the document (2. request).
>
> makes sense ?


If you mean do the two requests make sense, then yes. Or better yet, you
could just try to put, and if it fails, request the latest rev and give it
to your user to merge (or if you can do so algorithmically, then have at
it).

>
>
> thanks
> ./allan
>