[
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)
