Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of b.candler@pobox.com designates
 207.106.133.19 as permitted sender)
Date: Thu, 29 Jan 2009 21:00:09 +0000
From: Brian Candler <B.Candler@pobox.com>
To: user@couchdb.apache.org
Subject: Re: Trouble with replication
Message-ID: <20090129210009.GC28166@uk.tiscali.com>
References: <20090128153026.GA12384@uk.tiscali.com>
 <6C6796D4-1766-4526-A9C1-A4872C935337@gmail.com>
 <20090128162332.GA13801@uk.tiscali.com>
 <20090128165433.GA14192@uk.tiscali.com>
 <BF91C4EF-D461-4EF6-B399-60AB20849E1B@gmail.com>
 <20090128184531.GA15706@uk.tiscali.com>
 <9C0E9C8B-C783-47DE-8504-2CDC98650D99@apache.org>
 <20090129090318.GB6509@uk.tiscali.com>
 <e282921e0901290950n18a29409o2de847c1d1fb594e@mail.gmail.com>
 <91CE1D9D-2D5A-40BA-8D20-D24559BBA0F0@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <91CE1D9D-2D5A-40BA-8D20-D24559BBA0F0@apache.org>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

>> No. Side effects in that function become would deeply confusing, as it
>> runs during replication as well as for client-updates.
>>
>
> Indeed.

I had originally considered that replication would have to run as some sort
of admin user, so that all updates propagate successfully.

I can see that replicating as a normal user could useful in "peer-to-peer"
applications, but does this not introduce another sort of replication
conflict: a change is made on A but cannot replicate to B because access
controls prevent it?

>From the experiments I've seen so far, conflicts only occur on the
*incoming* side; so no conflict would be marked on the A side.

> My thinking to fill in the gap is we will provide something like a  
> server side stored procedure
...
> {
> id:"_design/foo",
> procs:{
> 	update_article: "function(editDoc, userCtx) {var prevDoc =  
> load_prev_rev(editDoc);  add_diffs(editDoc, prevDoc};  save(editDoc)}"
> 	},

Looks sensible. Is this similar to action.js ?

Would you expect save(editDoc) to bypass access controls? That would let me
use access controls to block direct PUTs to the document, whilst the stored
procedure could make whatever updates it needs, even though it was called
from an unprivileged userCtx.

Regards,

Brian.