🚀 go-pugleaf

Hi!

I've been thinking about designing a replicator.
I've come across a problem. I was thinking of using triggers to generate 
a log of all changes in a log table in the database (I think this is how 
other replicators work, right?). However, I need to do 2-way 
replication. So when database A receives a change from database B, it 
will apply the changes to itself. But then, the triggers will get fired 
in database A, and the same change will get sent back to database B. How 
can this sort of thing be prevented?

Also, another similar problem I've run into, is that if I have triggers 
for synchronising all data tables, what happens if there are already 
other triggers? For example, suppose table A has an After Update trigger 
that inserts data into table B. If I use triggers to generate the log, I 
will get the update statement for table A as well as the insert 
statements for table B. However, when the changes are applied on the 
other database, the inserts on table B will be done twice due to the 
triggers! How can I get around this?

Is there any alternative to using triggers? What do other replicators do?

I've found a way to overcome such problems as conflicts in primary keys, 
  foreign keys, and concurrent updates and deletes (using a lock table 
in the main database). So with a bit of recoding, I should be able to 
adapt my application to that fairly easily. All I'm missing now is to 
overcome a few technical barriers...

I need to have 4 databases entirely synchronized. Currently, the remote 
clients are connected directly to the main database via an ADSL 
connexion. But as this is too slow. So using the permanant connexion, I 
should be able to solve all potential conflicts.

Any help would be greatly appreciated!

Thanks!

Jonathan Neve.