couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: Trouble with replication
Date Thu, 29 Jan 2009 21:10:39 GMT

On Jan 29, 2009, at 4:00 PM, Brian Candler wrote:

>>> 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?

It's not a conflict, the edit document is simply refused by B. The  
replication of the remaining documents will continue.

If a user on B also edits the document and it replicates to A, then  
users of A will see a conflict, but users on B will not.

>
>
> 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?

Yes.

> 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