Jeff, thank you for your response, I realaly appreciate it, this is driving me slightly mad and there's a lot in here for me to try. Thanks also for the offer of help decoding the logs, I may well take you up on that. It's going to take me a couple of days to get into a position to try this out properly but I will be back...
Regards Simon --- In flexcoders@yahoogroups.com, "Jeff Vroom" <[EMAIL PROTECTED]> wrote: > > 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 >
