Anyone bold enough to have a look at this one?  It is a real headache
for me and the cause of increasing amounts of BS code to cope with it.
 I would really appreciate some help.

I seem to be getting object instances changing across a commit()
boundary. Half the object ID's change through a commit for no
apparent reason. This means I have no capability to manage a
parent-child relationship in data. Utter disaster!

Here's the situation. I have a parent child hierarchy of objects,
from the root to the leaves:
PO
PP
SS
SC
OP
So PO's contain PP's, PP's contain SS's and so forth.

I converse with a single data service which delivers a set of PO's and
the PP's are thereafter lazily loaded. I don't break the dataservice
or object model anywhere below that, so a PP is treated as a single
entity and read and written as such with its entire sub-graph of objects.

I have two destinations, one for PO's and one for PP's and this all
works fine.

However, when I create a graph such as the one above and commit it to
the server through the PO destination I have different object
instances for SS, SC and OP's after the call to commit returns.

This is a problem because there are some properties which are specific
to the object instance, in particular an object reference to its
parent. The object instance of the parent is changing across the
commit boundary.

Before commit everything is joined up nicely as you would expect:

PO @42f2451
PP @43f3629 parent @42f2451
SS @4c0ee71 parent @43f3629
SC @a5d69d1 parent @4c0ee71
OP @a2f5a01 parent @a5d69d1

after commit these are the same...

PO @42f2451
PP @43f3629 parent @42f2451

however everything else is different

SS @4c0e151 parent @a94d3d1
SC @4ba2d31 parent @4c0e151
OP @<new> parent @4ba2d31

what's worse is that the new parent instance of PP held on the new SS
(i.e. whatever is under @a94d3d1) has itself a null parent reference.
That means that after the commit my tree below SS is dangling in the
wind and I cannot find the parentage up to PO!

This is a complete disaster. It effectively means I have no
bi-directional one-to-many support, e.g. no Parent-Child, the most
basic of relationships!

Worse, if I traverse down from PO to OP I cannot traverse back up
again! It goes down one path and up another which ends before it gets
to PO.

So I have three questions:

What am I doing wrong?
How do I prevent my object instances from being screwed around with
during commit?
How do I tell when commit() has finished? Is there an Event I can
trap for its completion? Then I could at least repair my tree.

very glum...

SP

Reply via email to