[
https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683328#action_12683328
]
David Van Couvering commented on COUCHDB-223:
---------------------------------------------
Here's the first draft of this. It is missing example code, but I thought you
could review the overall description of the problem and new semantics while I'm
poking around trying to figure out what the example code should look like. The
tests are written in JavaScript, and I can pull that code for an example, but
shouldn't I also describe what the underlying HTTP request should look like?
In previous releases of CouchDB, bulk updates were transactional - in
particular, all requests in a bulk update failed if any request failed or was
in conflict. There were a couple of problems with this approach:
- This doesn't actually work with replication. Replication doesn't provide the
same transactional semantics, so downstream replicas won't see "all-or-nothing"
transactional semantics. Instead, they will see documents in an inconsistent
state until replication of all documents involved in the bulk update completes.
With bidirectional replication it can get even worse, because you can get edit
conflicts that must be fixed manually.
- If your database is partioned (aka "sharded"), different documents within the
transaction could live on different nodes in the cluster, and these kinds of
transactional semantics don't work unless you use heavy, non-scalable
approaches like two-phase commit.
With release 0.9 of CouchDB, transactional semantics have been changed to make
sure CouchDB works well in replicated and partitioned environments. There are
now two transactional models supported:
QUESTION: how does the user control which transactional model is used?
- all-or-nothing - When using _bulk_docs to update a set of documents, either
all the documents will commit successfully or none will. However, it does not
do conflict checking the documents will be committed even if there are
conflicts. Conflicting versions of the document will be saved. To use this
approach, set the all_or_nothing flag when issuing a _bulk_docs request.
TODO: Provide example code here...
- non-atomic - In this mode, some documents may successfully be saved and some
may not, and it is up to the application to check that all documents were
successfully saved/updated.
> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
> Key: COUCHDB-223
> URL: https://issues.apache.org/jira/browse/COUCHDB-223
> Project: CouchDB
> Issue Type: Improvement
> Components: Documentation
> Reporter: Jan Lehnardt
> Priority: Blocker
> Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour
> of multi-node partitioning, this behaviour goes away and bulk writes will
> behave a lot like and async writes and we should document the preferred way
> for clients to find failed writes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
