Richard Monson-Haefel <[EMAIL PROTECTED]> wrote:
>Bi-directional relationships create some interesting situations, when
>concerned with establishing relationships between two participants. The
>following scenario illustrates a problem that I would like vendors to
>comment on, if they are up for the challenge.
>
>Assume that SalesRep has a one-to-many bidirectional relationship with
>Customer.
>
>------------------
>
>SalesRep rep = SalesRepHome.findByPrimaryKey(somekey);
>
>Customer cust = CustomerHome.create( );
>
>cust.setSalesRep( rep);
>
>Colleciton colleciton = rep.getCustomers( );
>
>if(collection.contains( cust ))
> flag = true;
>else
> flag = false;
>
>-------------------
>
>What is the value of flag? I suspect it should be true in this
>scenario.
The flag will be true only if the implementation of setSalesRep() does
rep.add(this) where this is the Customer EJBObject. Alternatively if the
sales rep => customer relationship has been established prior to this chain
of events the flag will be true.
Are you perchance after a mechanism where either side (rep -> customer,
customer -> rep) of the relationship is automatically updated?
If so, then I don't think containers do that: you have to "manually" update
both sides. The convention is to do it from the one side (sales rep) in the
many direction (collection of customers or in the session bean that wraps
them.
>However, what would happen if the Colleciton of Customer references was
>obtained before cust set rep in its salesRep relationship field?
>
>--------------------
>
>SalesRep rep = SalesRepHome.findByPrimaryKey(somekey);
>
>Collection collection = rep.getCustomers( );
>
>Customer cust = CustomerHome.create( );
>
>cust.setSalesRep( rep);
>
>if(collection.contains( cust ))
> flag = true;
>else
> flag = false;
>
>-------------------------
>
>In this case the flag should still be true, IMO, but it may not for some
>containers. The specification warns against modifying a Collection
>based relationship field when perusing a Interator of that Collection,
>but it doesn't, to my knowledge, address this situation.
Interesting situation. Since the spec does not prohibit passing the return
values by reference (unless the definition of 'parameter' includes return
values), the flag could be true if 1) the reference to Collection of
customers is returned 2) setSalesRep(...) updates the aforementioned
collection. If the clone of the collection is returned then I don't see how
the flag could be true.
Alex Smith
Insight LLC
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
