couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: [VOTE] Apache CouchDB 0.9.0 release
Date Wed, 25 Mar 2009 11:44:07 GMT
On Wed, Mar 25, 2009 at 12:18 PM, Tim Parkin <> wrote:
> Chris Anderson wrote:
>>> I'd be interested in knowing what happened to the community discussion
>>> around the removal of the bulk_docs 'feature'? I've tried to raise this a
>>> couple of times but had little reaction. Am I right in understanding this
>>> lack of reaction as meaning there is going to be no discussion?
>> We've been concentrating on bulk docs documentation. In my experience,
>> most people who understand that the unit of consistency is the
>> document start to see ways of solving problems that work in a
>> key/value world. Some use-cases don't fit, but for the 80% case we're
>> better off with the simpler consistency model.
> I think the real issue is one of misunderstanding.. I personally just
> want a way to rollback changes in order to deal with user interface
> issues. The document I posted discusses the issue and highlights the
> fact that the problem is not about consistency, it's about providing a
> way to rollback changes if part of them fails so that a user can apply a
> change by clicking submit and get a success/fail response.

I think I understand the issue. I think there are two ways to approach
a solution. One is to confine end-user updates to a single key. This
approach is the classic model for key/value stores.

If your domain requires that edits are saved in multiple documents,
the complexity grows. If you can control replication, and ensure that
each user has a node to themselves, then you can treat edits between
replications as a transaction, and the application can roll back any
thing that has happened since the last outbound replication. It would
require a library between the UI and storage if you want to make that
simple for the user.

If you are working in an environment where the application can't treat
replication as a (soft) transaction boundary (hot-swap, or multiple
concurrent users) then you'll need to break updates out into
individual documents. A user can start an interactive transaction, and
mark all updates with the transaction id. Then you can use a view to
show only updates that are associated with a closed transaction.

In this explicit-transaction use case, non-committed updates may be
replicated, and it is the responsibility of the application to read
data through a view which only shows updates that belong to finished

The upshot is that bulk_docs can't and shouldn't give you any powers
that you don't have available with the individual document APIs, but
that doesn't mean your application can't provide those sorts of

> ... snip ...
>> I think the general understanding is that CouchDB is built with a
>> certain minimalist simplicity in mind. We appreciate that some of our
>> users have demands that exceed our out-of-the-box functionality. I
>> think once we have a solid understanding of how to use CouchDB in a
>> distributed manner, we'll be on steady footing for more ambitious
>> consistency guarantees.
> Just to reiterate.. it's not about consistency, it's about showing users
> a logical success/fail rather than saying to them.. "well a part of your
> change worked, part of it didn't - what would you like to do now?".
> The document I posted (I'll write a blog post about it if it helps)
> details the issue.
> Tim

Chris Anderson

View raw message