couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: Restricting user interactions to a single document -- was [VOTE] Apache CouchDB 0.9.0 release
Date Wed, 25 Mar 2009 19:12:01 GMT

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  

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


View raw message