couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Parkin <i...@timparkin.co.uk>
Subject Re: Restricting user interactions to a single document -- was [VOTE] Apache CouchDB 0.9.0 release
Date Wed, 25 Mar 2009 12:50:01 GMT
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. It's a pretty fundamental restriction and
one I'm sure people who want to use CouchDB would want to know about.

Tim


Mime
View raw message