couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
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  
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

Mime
View raw message