On Thu, Mar 26, 2009 at 6:00 PM, Tim Parkin <[email protected]> wrote: > Antony Blakey wrote: >> >> On 26/03/2009, at 6:18 AM, Tim Parkin wrote: >> >>> I don't want to have to repeat myself but *it's not about the >>> consistency or atomicity*. It's about being able to make two or more >>> changes in a single request (via a UI or API) and if the last one fails, >>> being able to roll the first ones back and tell the user "Sorry, >>> something went wrong, would you like to try again" instead of "you have >>> a partial success, how would you like to deal with it?" >> >> In what way is that not atomicity? > > Well the difference is I'm more interested the ability to rollback than > the atomicity. The philosophical objection (AFAICT) is to the atomicity > of bulk_docs. So if we can simplify the rollback that would be goal > number 1 acheived..
There is a ticket to allow a database to be rolled back to a specific sequence id. Of course it can not be rolled to a seq-id that is older than the last compaction. https://issues.apache.org/jira/browse/COUCHDB-120 With this implemented, if a user has a node to themselves, they can always roll back to an earlier state. Replication to a remote master node would be the equivalent of committing the local transaction. Of course other users of the remote master will see intermediate as the replication proceeds, so it's not really a transaction, just the ability to rollback some actions. Chris -- Chris Anderson http://jchrisa.net http://couch.io
