On Fri, Mar 6, 2009 at 1:58 PM, aju <[email protected]> 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
