incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: put and no _rev
Date Fri, 06 Mar 2009 19:37:02 GMT
On Fri, Mar 6, 2009 at 1:58 PM, aju <aju@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

Mime
View raw message