This relates to your other question about the association tags in the <metadata> section. There are two ways you can work with non-primitive object properties using FDMS. You can either have them be "managed associations" or you can treat them as "hierarchical values". If you choose the former, you define a destination for each data type and explicitly define the relationships using the <metadata> tags: one-to-many, one-to-one, etc (FDMS only pays attention to the ...-to-one or -to-many suffix as it only cares about whether the association is single or multi-valued). In this approach, each destination deals with the changes made to objects of that type. If you create a new child object and add it to a property on the parent for example, it will send the create event to the child destination and then send an update event to the parent destination. These are both executed in the same transaction so they will both get committed at the same time.
When you use the hierarchical values approach, the entire object graph underneath that property is treated as a single value. Any changes made to any state under that property is treated as a change to the property's value. FDMS reports the change to the parent object's destination and only tells you that the property of the parent changed. We do give you the complete old and new values though of the parent object so you can walk down and compare them to figure out the details of what changed. Whenever you use this approach, the entire object graph gets shipped back and forth for each change so it gets inefficient as the object graph gets bigger. In this particular case, it sounds like the managed association feature would be the best approach. You can create new objects on either the client or the server - whichever makes the most sense for your application. Simply adding a new object to the property of another managed object is enough to "create it" for the system. We'll detect that it is a new object and log both the create and update operations as part of the batch. When you issue the "commit" call, both are sent to the server as part of the same batch. Jeff ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of simonjpalmer Sent: Sunday, January 28, 2007 12:56 PM To: [email protected] Subject: [flexcoders] parent-child hierarchy of data using Flex, FDS and Hibernate Hi, I have a 4 level hierarchy of data in my application with a bi-directional one-to-many relationship between each level as follows: PlanPoint (parent) -- UserScenario (child) ---- Scenario (grandchild) ------ Competitor (great grandchild) I have a hibernate back end running under JBoss and I am using FDS to synchronise the changes from my Flex UI. My DB will be Oracle, but for the time being I am just testing with a HSQLDB for convenience. I have managed to create a destination in FDS which will retrieve the parent objects. The hibernate mapping docs specify the further retrieval of the graph of objects attached to them. This all works fine and performs reasonably well, although I have been unable to get any meaningful lazy loading to work (a problem for another time). My problem comes in that the user will interact deeply with the graph of objects during the client session. This includes adding, removing and updating objects at all levels. What I can't seem to get right is the interaction in the Flex layer which copes with this level of interaction. For instance if I want to add a new Competitor to a Scenario do I (i) create all new objects on the client and then synchronise the server, or (ii) initiate creation of a new object on the server and then modify it on the client? I seem to have problems in both directions and the same isue for delete and to a certain extent modify. I only have a single FDS destination defined, so any alterations appear to go through the PlanPoint Object at the root of the tree and as a result much more data gets passed back and forth than I would like. I'm not sure if I am just a little simplistic in my design and need more sophistication in my relationship between the client and server, or whether I just need a bit more code in my client to manage the object state. Any guidance would be greatly appreciated as I'm beginning to swim in circles.
