Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <EAE34F09-C3E8-4E39-8AA1-0B977469259D@apache.org>
From: Damien Katz <damien@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <49CA2879.3070502@timparkin.co.uk>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Restricting user interactions to a single document -- was [VOTE]
 Apache CouchDB 0.9.0 release
Date: Wed, 25 Mar 2009 15:12:01 -0400
References: <20090324140050.GA17574@tumbolia.org>
	 <49C9776E.1060804@timparkin.co.uk>
	 <e282921e0903241905g4cb9e881ha99ecf739e5c51f0@mail.gmail.com>
	 <49CA1307.7060300@timparkin.co.uk>
 <e282921e0903250444o28d98f38v42dc49bb5a284cd7@mail.gmail.com>
 <49CA2879.3070502@timparkin.co.uk>


On Mar 25, 2009, at 8:50 AM, Tim Parkin wrote:

> Chris Anderson wrote:
> -- aa --
>>
>> 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.
>
> Pretty unfeasible I would think..
>
>> 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.
>>
>
> Fairly unfeasible for a database with 1m+ users.. and I imagine it  
> won't
> be particularly fast to re-replicate the whole db on failure.
>
>> 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.
>>
>
> Which isn't particularly straightforward either and you lose lots of
> couchdb features (like conflict management) plus, as you say, you need
> to monitor replication etc..
>
>> 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.
>
> The upshot appears to be that CouchDB is limited to only changing a
> single document at a time through a user interface (unless you want to
> add lots of work to handle conflicts).. Could I have a confirmation of
> this so I can blog about it.

That pretty much true, CouchDB offers no inter-document consistency  
guarantees.

> It's a pretty fundamental restriction and
> one I'm sure people who want to use CouchDB would want to know about.

You could help by updating the wiki documentation to make this  
clearer.  Multiple places if necessary.

-Damien