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
