Answers inline:

 

________________________________

From: [email protected] [mailto:[EMAIL PROTECTED] On
Behalf Of simonjpalmer
Sent: Monday, May 07, 2007 11:34 AM
To: [email protected]
Subject: [flexcoders] Re: Help! Object integrity across
DataService.commit()

 

Anyone else trying to lazily load a parent-child relationship with
fds? The more I look at this the more I think it may be the key to
solving my problem. 

I have some fundamental questions:
1. What *should* I return as the parent object on the child when I
return an object in response to an itemPendingError accessing the
children collection on the parent?

[Jeff] You return an instance of the parent where only the id properties
are populated (assuming that the parent reference is marked with
lazy="true" on the association tag which is highly recommended).  


It seems crazy that I should look the parent up again and return a
fully populated object (the state may have changed in the client so
that would be wrong). If I send back a partially populated parent
object containing the identity I seem to get another itemPendingError
when I access the parent object, which I know I already have or I
wouldn't have the child! So that doesn't look right either. 
Returning null means that my child contains a null parent, which is
also wrong.

2. After a commit I seem to get a repeat call to the original fill
method. Why? How can I avoid this? It is not logically correct for
me to be passing the parent layer of the lazily loaded objects back
again for a second time.

Anyone have any clues? Either I am doing something stupid (likely) or
bi-directional one-to-many does not work properly (less likely, but a
possibility). or maybe it works as intended but my understanding of
it is wrong.

Either way, I still have a pretty serious problem traversing backward
through my parent references in a graph of objects which ought to be
able to maintain itself. This problem remains unsolved.



[Jeff] If the fill method is using the "auto refresh" functionality, it
will call the fill method once for each batch of changes where you have
created or updated items that might be returned by this fill.   If you
turn off auto-refresh, it won't call the fill method again in that
situation. 

Jeff



--- In [email protected] <mailto:flexcoders%40yahoogroups.com>
, "simonjpalmer" <[EMAIL PROTECTED]>
wrote:
>
> Pete / Jeff.
> 
> I think I need to start from the basics here. I have been poring
> through endless logs but I have some unanswered questions at the
> beginning which I think I need to sort out first. 
> 
> The basic unanswered issue for me is that when I lazily load a child
> the parent reference is null. I never do anything to address this in
> code (i.e. I do not populate the parent object reference). Should I?
> 
> Here is what my destinations look like (.'s for readability):
> 
> <destination id="portfolio.spring">
> .<adapter ref="java-dao" />
> .<properties>
> ..<source>beanPortfolioAssembler</source>
> ..<factory>spring</factory>
> ..<metadata>
> ...<identity property="uid"/>
> ...<one-to-many property="planpoints" destination="planpoint.spring"
> lazy="true"/>
> ..</metadata>
> .</properties>
> </destination>
> 
> <destination id="planpoint.spring">
> .<adapter ref="java-dao" />
> .<properties>
> ..<source>beanPlanPointAssembler</source>
> ..<factory>spring</factory>
> ..<metadata>
> ...<identity property="uid"/>
> ...<many-to-one property="parent" destination="portfolio.spring"
> lazy="true"/>
> ..</metadata>
> .</properties>
> </destination>
> 
> Notice there is a bi-directional one-to-many relationship, both ends
> of which are defined as lazily loaded. My flex application has
> DataService object which is bound to portfolio.spring. I call the
> standard fill method supplying an ArrayCollection object to hold the
> results and the ID of the currently connected user:
> 
> [Bindable] public var activePortfolios:ArrayCollection = new
> ArrayCollection();
> 
> private var ds_po:DataService = new DataService("portfolio.spring");
> 
> private function getPortfolios(authenticatedUser:User):void
> {
> ..ds_po.fill(activePortfolios, authenticatedUser.uid);
> }
> 
> I have no client reference to planpoint.spring. On fill I populate
> and return a list of Portfolio objects. Each Portfolio object has a
> Set called "planpoints" which I populate with PlanPoint objects which
> are empty except for their uid. This means I do not send back a
> populated parent reference in the initial fill from portfolio.spring.
> I'm not sure whether that is correct or not. Can I rely on data
> services to wire that up correctly or should I be sending back a stub
> Portfolio object with its uid?
> 
> Here is what my value objects look like. I am omitting most of the
> pojo code for brevity, all members are accessed by standard getters
> and setters. I have an equivalent set of AS objects on the flex side:
> 
> public class Portfolio extends PojoBase implements IPojo
> {
> ...
> ..private String uid = new String();
> ..private Set<PlanPoint> planpoints = new HashSet<PlanPoint>();
> ...
> }
> 
> public class PlanPoint extends PojoBase implements Serializable, IPojo
> {
> ...
> ..private transient Portfolio parent;
> ..private String uid = new String();
> ...
> }
> 
> So on initial fill I have:
> PortfolioObject
> ..uid="XXX"
> ..planpoints
> ....PlanPointObject
> ......uid="YYY"
> ......parent=null
> ......everythingelse=null
> 
> I then get server side calls through planpoint.spring when the lazy
> loading of the children kicks in. The getItem calls contain the uids
> of the partially populate objects that I returned on fill as expected.
> I then send back fully populated PlanPoint objects EXCEPT I never
> populate the parent. Not surprisingly when my PlanPoint arrives on
> the client side it has a null parent.
> 
> PlanPointObject
> ..uid="YYY"
> ..parent=null
> ..everythingelse=something
> 
> What should I be sending back? The back reference to the parent is
> lazily loaded accorinding to the definition of planpoint.spring above
> and the PlanPoint is being returned in response to an itemPendingError
> on the client side because a stub PlanPoint is being accessed in the
> context of a Portfolio. The Portfolios live in a managed collection.
> Should I reply to the planpoint.spring.getItem message with a
> PlanPoint object containing a stub Portfolio object with its uid
> populated?
> 
> I think that until I make sure I have this part correct it is useless
> for me to look deeper into my issue. 
> 
> Am I doing the right thing here?
> 
> As ever I really appreciate your help. This is currently standing
> between me and production code.
> 
> Simon
>

 

Reply via email to