couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Trouble with replication
Date Thu, 29 Jan 2009 21:00:09 GMT
>> 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.

Mime
View raw message