Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <01DCAC9E-0125-46EA-876E-12B685C40DFC@apache.org>
From: Damien Katz <damien@apache.org>
To: user@couchdb.apache.org
In-Reply-To: <20091101220729.GB19849@uk.tiscali.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: all_or_nothing=true and replication
Date: Sun, 1 Nov 2009 17:36:18 -0500
References: <20091101220729.GB19849@uk.tiscali.com>


On Nov 1, 2009, at 5:07 PM, Brian Candler wrote:

> At http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API I see the
> following:
>
> "Bulk updates work independently of replication, meaning document  
> revisions
> originally saved as part of an all or nothing transaction will be  
> replicated
> individually, not as part of a bulk transaction. This means other  
> replica
> instances may only have a subset of the transaction, and if an  
> update is
> rejected by the remote node during replication (e.g. not authorized  
> error)
> the remote node may never have the complete transaction."
>
> I had a vague idea from the original discussions that these  
> transactions
> would remain together, but this appears to be wrong.
>
> I'd just like to ask if the lack of boundaries for replication is
> intentional behaviour, or just an artefact of the current  
> implementation
> which might change?

It's intentional behavior. Documents are meant to be independent, even  
conflicts..

>
> I can think of circumstances where it might be useful to keep them  
> together.
> Consider, for example, an all_or_nothing transaction which is used to
> resolve a conflict between three documents: it does this by writing  
> a new
> revision, and deleting the other two revisions.
>
> If this set of updates became split upon replication, it might end up
> deleting the two old revisions but not updating the other document;  
> thus you
> would have lost data from those two revisions.
> Any thoughts or comments?

Yes, you can make a situation where somehow a user has legal updates  
to certain conflicts, but not others, on a particular node A. On some  
other node B, somehow the security was different and he was allowed to  
update all the docs. Then an attempt to merge all the conflicts into  
the document the user didn't really have edit access too will not be  
replicated from node B to node A.

It's a contrived situation, but possible with misconfigured or updated  
security settings that haven't propagated.

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.

-Damien

>
> Regards,
>
> Brian.