On Thu, Jan 29, 2009 at 3:12 PM, Antony Blakey <[email protected]> wrote: > > 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.
What's happening in this scenario is that B is not getting any revs from A. Replication is one-way. I think if you always trigger replication both ways, then your nodes will be consistent (assuming they accept the same set of updates as valid). > > 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. > > > -- Chris Anderson http://jchris.mfdz.com
