🚀 go-pugleaf

> I handle this in my own replicator, but I have a completely different
> approach, which makes it easy. If you log every change, indicating
> whether it is an INSERT, an UPDATE or a DELETE, and then you replicate
> this change in the same way to the other side (if I understand
> correctly, this is how IBReplicator works), then it will be very
> difficult to handle PK changes. Suppose in DB 1, a user inserts a record
> with PK=34, and then updates it to 35 before replicating. When the
> replicator starts, it will see two changes : one insert, and one update.
> So it will try to perform the insert, but it won't succeed, since the
> record referenced by the line in the replication log corresponding to
> the insert, no longer has any corresponding record. Then, the update
> also doesn't work, obviously, since the insert didn't.

Er no. Only committed changes get replicated.
So this would really be insert PK=34 commit - Write replication insert to
replication log.
Then the insert takes place on the target with PK=34 data=blah

Now if you update the primary key, and make it 35, commit,  an update would
fail on the
target because replication expects to find the same primary key in the target
database
as the source i.e. update 35 which doesn't exist. Changing primary keys in
distributed databases (which includes replicated ones) is not the brightest
move.

Paul