Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 209.85.198.239 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=rJoLkt3wOHjbT0CctW1kFKN2pYebUX+Uyozwrd2rgTSxftSI0hgDJnRZDFP/eWvUIR
         00pf2LdNv+tDnmdDBJMLPSug0AtPj+HNTuqwC5UCvPHc8SEMMM3cD3hqWQEEEfmJsbVM
         3izfCTLhoMv72aiIhY1yraqHU1NjksQnyhUyE=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <49CA1307.7060300@timparkin.co.uk>
References: <20090324140050.GA17574@tumbolia.org>
	 <49C9776E.1060804@timparkin.co.uk>
	 <e282921e0903241905g4cb9e881ha99ecf739e5c51f0@mail.gmail.com>
	 <49CA1307.7060300@timparkin.co.uk>
Date: Wed, 25 Mar 2009 12:44:07 +0100
Message-ID: <e282921e0903250444o28d98f38v42dc49bb5a284cd7@mail.gmail.com>
Subject: Re: [VOTE] Apache CouchDB 0.9.0 release
From: Chris Anderson <jchris@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Mar 25, 2009 at 12:18 PM, Tim Parkin <info@timparkin.co.uk> 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
transactions.

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
interfaces.

> ... 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
http://jchrisa.net
http://couch.io