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
