This relates to your other question about the association tags in the
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 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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of simonjpalmer
Sent: Sunday, January 28, 2007 12:56 PM
To: flexcoders@yahoogroups.com
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.
