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.
