More about RelationsChangeLog

[Damián]

I've made the following tests:

Test 1:

doInTxn {
obj1.addNtoNRelation(obj2)
}
doInTxn {
obj1.removeNtoNRelation(obj2)
}
=> RelationsChangeLog has entries both for the "add" and the "remove"

Test 2:

doInTxn {
obj1.addNtoNRelation(obj2)
obj1.removeNtoNRelation(obj2)
}
=> RelationsChangeLog has an entry only for the "add"

This last case leads to an incorrect result when replicating the
changelog: it creates a link between objects in the target DB which is
not present in the source DB. Did I miss something here?


Damián

[Joao Cachopo]

Damián <damian....@gmail.com> writes:

Are you sure that the entry for the RelationsChangeLog is for the "add"
and not for the "remove"?

Because what should happen is that the second line (the remove) would
replace the add. The result that you're saying that you get should
result only if the two lines are swapped.

--
João Cachopo

[Damián Arregui]

2009/6/23 Joao Cachopo <joao.c...@ist.utl.pt>

>
> doInTxn {
>       obj1.addNtoNRelation(obj2)
>       obj1.removeNtoNRelation(obj2)
> }
> => RelationsChangeLog has an entry only for the "add"

Are you sure that the entry for the RelationsChangeLog is for the "add"
and not for the "remove"?

Because what should happen is that the second line (the remove) would
replace the add.  The result that you're saying that you get should
result only if the two lines are swapped.

Just double-checked and it is indeed an "add" entry. The remove boolean is set to false.

Damián

 

[Joao Cachopo]

Damián Arregui <damian....@gmail.com> writes:

> Just double-checked and it is indeed an "add" entry. The remove
> boolean is set to false.

Yes, meanwhile I was testing it myself and I found out the problem.

I've already committed the fix.

Thanks, Damián.
--
João Cachopo