Hi Bruno,
I think the bug is due to the flush and markDelete.
you are right, the bug is indirectly caused by the
TransactionExt.flush() call.
In this case OJB reuse all registered object entries but doesn't clear
1:1, 1:n link history. Thus these operations will be called again on
next
Hi Bruno,
Bruno CROS wrote:
Hi,
well, if i do not flush, process can't work. We tried to avoid them, but
process seems to not (several circular references as i explained you a few
days ago)
I didn't get OJB test suite running (without any change of 1.0.4 binary
dist). the DB creation step
Hi Bruno,
I setup a similar test in CircularTest#testBidirectionalOneToOneMoveObject()
http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?rev=386117view=markup
The test works like a charm.
Compared with your post this test doesn't
Hi,
well, if i do not flush, process can't work. We tried to avoid them, but
process seems to not (several circular references as i explained you a few
days ago)
I didn't get OJB test suite running (without any change of 1.0.4 binary
dist). the DB creation step crashes with an unknown CLOB
Hi Armin, Hi all.
Well, with a little confusion, we believed that our bug of complex update
was not one. But it remains.
I'm suspecting a bug of OJB concerning the transcription of the
markDelete in SQL operations.
If I have time, I will try to assemble a demonstrative case of test with
