On 30/01/2009, at 7:40 AM, Damien Katz wrote:
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.
So replication doesn't necessarily result in consistent state between
nodes, with the further result that p2p meshes need to be aware of
this because homogeneity of the mesh would depend on maintaining a
consistent global order of updates, which isn't possible.
Does this mean that this statement on the wiki overview: 'When
distributed edit conflicts occur, every database replica sees the same
winning revision' is no longer true?
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Don't anthropomorphize computers. They hate that.
