NYCPHP Meetup

[bzcoder]

bzcoder wrote:
> Allen Shaw wrote:
>> Hi Gang,
>>
>> Banging my head against this wall, wondered if you all might know 
>> something I don't.  (It does happen often, I find.)
>
> Well, it all depends on how you engineer the thing.
>
> But something to look into is "replication"

Head, meet wall.

Sorry, here is a link on MySQL replication/conflict resolution:
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication-conflict-resolution.html


Something to note, it will not always be something that is just a simple 
"pick a timestamp" for conflicts, so this system will take some time and 
thought.

For example:
Customer A:
A Record(Name, Address, Favorite sport, whatever)

Customer B:
B Record(Name, Address, Favorite sport, whatever)

Room RC:
RC Record(Floor, keycode, type, etc)

Room RD:
RD Record(Floor, keycode, type, etc)

Reservations:
Customer A reserved room RC from June 1st to June7th
Customer B reserves room RC from June 5st to June 9th

Reserved Records:
Room RC, June 1st, Customer A
Room RC, June 2nd Customer A
Room RC, June 3rd, Customer A
Room RC, June 4th Customer A
Room RC, June 5th, (Repl conflict! Customer A or B)
Room RC, June 6th,  (Repl conflict! Customer A or B)
Room RC, June 7th,  (Repl conflict! Customer A or B)
Room RC, June 8th, Customer B
Room RC, June 9th, Customer B

The only conflict above would potentially be in the Reserved Records, 
all the other records can be updated independently. 

So not only do the 3 conflicted records need to be updated, but 
whichever customer loses must be re-registered for another room(and gap 
days reserved must be released.  If B was given the room, than the 1-4th 
records for customer A must be purged)


In the end, the /system/ you use for catching conflicts will matter less 
than the application you build to resolve them.