couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2065) Overwrite a document with a single request
Date Sat, 15 Feb 2014 11:33:19 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13902390#comment-13902390
] 

Robert Newson commented on COUCHDB-2065:
----------------------------------------

"the latest" is ambiguous though, which of the branches did each user intend to extend? Maybe
none of them, and they are making a new one. The while (409) reattempt() thing is important,
since *what* you 'reattempt' might change (you might even find that you should stop attempting,
because the change you would make now should not be made).

"most users are probably working with single-node architectures" -- I get that, but let's
remember what CouchDB is for. It exists to enable offline, disconnected synchronizing solutions,
something that's traditionally hard or broken in other databases. The "single node" semantics
of CouchDB is to reject your write with a 409 so that you generally do extend a linear history
for each document. When you go multi-node, this doesn't (can't) happen, and the concurrency
of writes is detected if and when you replicate the databases between the nodes by making
branches. We could change the single-node model to match that but it's not what you're asking
for here.

The closest solution to this that I can think of is Clojure's STM model. In cases where you're
updating variable under a dosync call, your function might be called many times. Clojure is
automating that 'oops it changed, try my change again' piece that you're advocating for. That's
a sane thing to do with the appropriate constraints, but we would want to model it as a function
not as a 'write this document'. It is the *change* you intend to make that can be repeated
(assuming it's side-effect free) not the 'overwrite'.

I'll finish with saying that we do accept that MVCC is a tough concept and that the CouchDB
API can seem onerous. As a team, I think it's safe to say we'd like to make this easier to
understand and easier to use correctly. What we won't do is throw the baby out with the bath
water and "overwrites" or "forced operations" seem to do that. We have a number of tickets
to change the API around this, in a major revision bump. For example, rather than hiding the
tree nature of documents, we thought we'd change the API so that a GET /dbname/docid would
return *all* leaves by default.

> Overwrite a document with a single request
> ------------------------------------------
>
>                 Key: COUCHDB-2065
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2065
>             Project: CouchDB
>          Issue Type: New Feature
>      Security Level: public(Regular issues) 
>            Reporter: Nolan Lawson
>
> It would be convenient to have the option to overwrite documents with a single request,
rather than having to GET, check the _rev, POST/PUT, possibly deal with conflicts, and then
continue POST/PUTing until success.  It could be something as simple as:
> {code}
> PUT localhost:5984/mydb/mydoc?force=true 
> {code}
> If two callers attempt to update the same document at the same time, whoever gets there
last would win.
> Prompted by a [discussion in PouchDB|https://github.com/daleharvey/pouchdb/issues/1388].



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message