Hi Armin. Hi all.
Ok. Well, i discussed about the bug with the developer who found it. After
we have inspected the code (really this time) we found the error.
There's no more bug about modifying objects after flush.
Now, we have established some important rules to code
ODMG transactions (never
Oups, a type error at the end of my mail.
I don't think i will test this deeper, because you warned me about doing
this (get object from other broker).
That explains the strange behaviour we had.
Regards.
Sorry for mistake.
On 3/7/06, Bruno CROS [EMAIL PROTECTED] wrote:
Hi Armin. Hi
Hi Bruno,
Bruno CROS wrote:
Our first problem was, that, after commit, P1 was not referencing M in
database. I deduced that after a flush(), new locked objects (before
flush)
can't reference new ones created before flush too (a second time). Humm,
strange... we check all code : No apparent
Hi all, hi Armin,
I believe i noted a strange behaviour behaviour of new 1.0.4 ODMG
ordering.
Consider JIRA OJB-18. Before 1.0.4 , we used the given workaround. This
means, that we put some flush() in strategical place to avoid all FK
constraints. It worked fine.
Now, with the OJB
Hi Bruno,
whew! Sounds really complex, I try my best...
The first problem is the bidirectional reference between P1, P2. To
establish the FK (e.g. in P1 from P2) the referenced object (P2) have to
be persistent (else the PK of P2 will be 'null' and OJB will set FK in
P2 'null' too).
In
