On 13 Aug 2015, at 4:03pm, sqlite-mail <sqlite-mail at dev.dadbiz.es> wrote:
> With that would be trivial to log the statements that change the database to > replicate elsewhere. As Jean-Christophe wrote, it's not that simple. There are huge books written on the problems involved in synchronising two copies of a database, and none of them end with a chapter called "Solution". Here's an example of one of many problems. Two copies of a database are maintained. In one copy, the following command is issued: UPDATE contacts SET town = "Cambridge" WHERE town = "Grantebrycge" In the other copy the following command is issued: UPDATE contacts SET town = "Camberley" WHERE town = "Cambridge" So when the databases are synchronised, one copy has command 1 then command 2, whereas the other copy has command 2 then command 1. Here's the result after the synchronisation: Original Copy A Copy B -------- ------ ------ Grantebrycge Camberley Cambridge As you can see, the two copies are not identical. And the resolution of the problem (deciding what /should/ happen) depends on the intentions of the users, which is something the software can't know. This is normally resolved by logging the time each command was issued and keeping a central copy of the database which remains unchanged when changes are made to the live copies. Upon synchronisation the change logs for all copies are merged in time order, and the resulting log is applied to the central unchanged copy. Then copies of this new version of the database are copied to each client. So now you need some sort of 'boss' node which does extra work. And even this still doesn't please users, some of whom will see their changes be ignored or changed again by other people. Simon.
