One of the features of Data Management is that the assembler can modify the objects involved in a create or an update. After the commit, these changes are applied to the managed copy. One common change made on the server is that during the create the server assigns new ids to the newly created items. If the assembler does not make any changes, nothing should be changed after the commit.
So I think the first step would be to turn on the debug level for the "Message.*" and "DataService.*" patterns in the server logs, and compare the before and after "create" and "update" events in the logs. For lazy associations, the state of the association properties is stored in the "referencedIds" headers in the messages. For non-lazy associations, if you put toString methods in your DTOs to dump out relevant info that is helpful. One more thing to try that may help. When the objects have lazy="true" (not the default) only the references to objects are updated. At most, data management has to update references to objects so the instances would only change if the ids were changed. When lazy="false" we recursively update the object graph for the properties changed which is more involved so you might try adding lazy="true". In particular, make sure that parent has lazy="true" as backptrs tend to perform and behave better when you are not sending the parent's state along with an update of the child. This does sometimes mean you have to catch and ignore ItemPendingErrors but usually this doesn't happen for parents. If you could use help analyzing the logs, send them along. Sometimes the client side debug log is useful in these situations too (<mx:TraceTarget/>). Jeff ________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of simonjpalmer Sent: Tuesday, April 17, 2007 7:20 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Help! Object integrity across DataService.commit() 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
