couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: all_or_nothing=true and replication
Date Tue, 03 Nov 2009 09:01:19 GMT
On Sun, Nov 01, 2009 at 05:36:18PM -0500, Damien Katz wrote:
> It's intentional behavior. Documents are meant to be independent, even  
> conflicts..
> However, if you doing this as a VCS where you keep all the diffs, then  
> simply put the edit history as diffs into even the deleted documents.  
> Deleted docs actually can have a body and attachments, for just this  
> reason. Then no data is lost even when weird security settings disallow 
> only certain replicated edits.

OK, I can see that there are workarounds for specific cases. But then the
same workarounds could be used on a single-node system too, without using

What I mean is: what exactly is the value of bundling a series of updates
together with all_or_nothing, if they become unbundled again upon
replication? If your application relies on all_or_nothing grouping to work
properly, wouldn't you just end up making it unable to work in a
multi-master environment?

Let me propose another example. Say you want to insert an entity A and two
child entities B1 and B2 - and you have a good reason for not wanting to
incorporate them into the same document. You don't want B1 or B2 to be
orphaned in the database without their parent A, so you insert them together
with all_or_nothing.

After replication, in the current model you *could* end up with orphans,
either because of update policy on the second node, or because of failures
occuring at just the wrong time.

Would it not be reasonable for them to replicate as a unit, and all fail to
replicate if any one is rejected? This would give you the same semantics
across the replication boundary.

I realise that you can get these semantics by replicating a single document
{A,[B1,B2]}. But if you were able to write your app that way, you wouldn't
have needed all_or_nothing in the first place, would you?



View raw message