On Mon, Jun 11, 2012 at 10:11:45PM +0000, Black, Michael (IS) scratched on the wall: > Answer: The most recent one. > > Isn't it true that semi-accurate (sub-second) time-tagged transactions > will generally keep 2 databases in sync?
"Generally", perhaps, but not always. > I've done that before with considerable success. You don't sync the > fields...you sync the transactions. The presumption is that later > transactions win regardless of intervening updates. The issue is with data history and multiple changes. Consider if two devices are sync'ed. Then a modification is made on device A. Then B. Then A again (without seeing B's modifications). Then the devices are sync'ed again. The data on "A" was the "latest" copy, but if "B" made changes to the same record, it is questionable about which is true. "A" might have made modifications to out-of-date data. Even if you play back the transactions, one by one, in order, that doesn't always help. You might find that "B" made a modification that makes "A's" second modification invalid, or that the modification would result in a different answer. If all you're talking about is an address book, it might not be that big of a deal-- especially if you can delineate the data. For example, if each atomic record is timestamped, you can generally just take the most up-to-date value of each record. It gets trick when data is added or deleted however, and even a simple address book application will typically allow people to add or remove multiple phone numbers, addresses, etc. for a given entry. For example, in my previous case, A modifies an existing address, B removes the address, A modifies the address again. OK, now what? There are a few options on how to deal with this, and the "right" choice is likely a combo of application needs and user expectations. > Only problem is when times are too close (beyond your time-sync > resolution) which requires human intervention...though in a user-driven > system that should be nigh on to impossible to create. That's the least of your issues. Assuming personal devices like an iPhone and iPad, there is a very good chance the clocks are kept well in-sync. Given that people don't tend to use those types of devices at the same time, to do the same task, I don't think this is a major concern. It might very well be a concern in other contexts, however... especially for devices that don't "live" on the network and have lots of chances to sync their clock. > I do realize the complexity of keeping two database in sync....but > transaction systems have been around for decades. Depends on your > application. Yes, it does depend, and that's just the point. The best example of this is likely source-control systems. And they're typically very complex, traditionally have a central "master" dept, and often require human intervention to untangle the mess when a merge goes wrong. They're actually an easy case. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
