Data silently mis-replicated leading to inconsistent publisher-subscriber state

[Jonathan]

Hello,

I was testing the trial version of daffodil replicator enterprise on
a mysql database. However, there seem to be some serieus issues with
the way how replication works, which can lead to silently skipped
data. This can
always be reproduced!

I will try to explain one of the cases as simply as possible, with a
simple sequence of sql statements and comments. The database used is
mysql5

--Initialize databases
CREATE DATABASE publisher;
USE publisher;
CREATE TABLE parent(
id int,
msg varchar(20),
primary key(id)
);
CREATE TABLE CHILD(
id int,
parent_id int,
msg varchar(20),
primary key(id),
foreign key(parent_id) references parent(id)
);


CREATE DATABASE subscriber;
USE subscriber
CREATE TABLE parent(
id int,
msg varchar(20),
primary key(id)
);
CREATE TABLE CHILD(
id int,
parent_id int,
msg varchar(20),
primary key(id),
foreign key(parent_id) references parent(id)
);

--Now in daffodil replicator(E):
-- Create datasources for both databases, include parent & child table
-- Create subscribtion so that the data flows from publisher to
subscriber
-- (publisher wins)
-- This configuration works correctly, inserts etc get replicated
perfectly
-- before AND after(but not during) the ignored one below.

--execute on PUBLISHER
use publisher
insert into parent(id,msg) values (1,'msg1');
insert into child (id,parent_id,msg) values (1,1,'refs parent1');
insert into parent (id,msg) values (2,'msg2');
update child set parent=2,msg='now refs parent2' where id=1;
--SYNC in daffodil
-- =>SILENTLY IGNORES THE CHILD ROW!
-- the subcriber child table is empty, the parent table contains
(correctly) two records
-- (child is missed probably because of an ignored internal foreign
key exception)
-- This can also happen between a set of other updates,
-- leaving the databases in an missynchronized state!


When I take a look at the metadata tables of daffodil it is clear why
this occurs The delta sent to the subscriber with each transaction is
not the original data for the changed record, but the current data.
Other scenario's to trigger a silent missynchronisation can easily be
designed. So, I have two questions:
1) Can you acknowledge the existence of this bug
2) Is it someday going to be fixed, or is that unlikely? I suppose it
will not be trivial, since this seems to be a limitation inherent to
how the replicator is designed.

Jonathan

[Nitin Goyal]

Dear Jonathan

The problem is known to us and it has been solved internally. You will
not find this kind of behavior in Replicator(E) 3.3.0 [yet to be
released].

Thanks
Nitin Goyal
Daffodil Replicator Team

[Jonathan]

Great, I'm looking forward to the new version.

Jonathan

[haotten]

Gould you provide us with an ETA on 3.3?

[Nitin Goyal]

Dear Otten

We will release Replicator E 3.3.0 within this month.

Thanks
Nitin Goyal