majority rule won't work. I'll explain below.
>
> This requires more than one peer -- not necessarily a good thing
> either. How about this:
>
> 1) Receive a duplicate, but not the same record from a peer
> 2) Toss the duplicate into a 'conflict bin' and save it for later.
> 3) Next time we receive this record from a peer we scan through the
> conflict bin to see if we already have a conflict for this record. If
> so, compare the newly received record, any records in the conflict bin,
> and the record in the DB. Accept the 'correct record' as determined by
> majority rule.
we fall into the same majority rule trap, and we still need more than one peer.
>
> Note that this process has no clue as to what the 'correct record'
> really is. If we then make it so that whenever a user corrects a record
> in the database, we update its timestamp so that it will go through
> another pull cycle by a peer. The peer is likely to have this record in
> its database, so it will toss the record into the conflict bin. Given
> this algorithm a change will only be accepted if two or more seperate
> people make the same correction. This also avoids single people from
> trashing the database.
>
> Does that make sense?
kind of...
Ok, I'll try to explain what I mean about the maj. rule problems.
take a simple server setup. 3 servers, A, B & C. each peers with the others.
server A gets a correct entry for a CD, server B gets an incorrect entry.
Server C pulls from server B first. Now server B & C have the incorrect entry.
Server A pulls from B, sees the conflict, throws it in the conflict bin to
deal with later. Then it pulls from C and checks the conflict bin. It sees
that there are more servers that have the other record, and replaces it's
correct entry, with the incorrect one.
I propose this:
Each server is going to have an admin (at least one). Conflicting records
are put in a report to that admin. The admin can then manually update
the record if they see fit. After they compare it to a few other servers or
the cd that they have. NOTE: by recognizing the conflicts, and reporting them
it would not be hard to make a proc to act on these conflicting records once
a procedure is decided upon. until that revision of the server, we just
deal with human intervention. If the server admin chooses to, he can ignore
the conflict list, and his server will just have some bad info.
And no matter what we choose, I'd suggest that each server have at least
2 peers. 1 peer servers run the risk of being orphans.
If we move forward with this plan, we can at least have mode some progress.
Later, we can decide what to do with the conflicts.
-- Rob