• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

One to Many Bidirectional Relationship

 
Santosh Ramachandrula
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reference EJB Spec 2.0 Final Release
Page: 139/140
Page 139 :
A and B are in one to many Bidirectional Relationship
Page 140:
Change:
a1.setB(a2.getB());
Expeced Result:

b2.isEmpty() ( I don't understand this, how come b2 is empty() )
b11.getA() == null ( how is is that A is null )

Can some one explain this?
 
Sankar Subbiramaniam
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I too had the same doubt. After a while, i can come up with the following reasoning:
Original status:
a1 is referring to b1 (collection CMR)
a2 is referring to b2 (collection CMR)

Change operation : a1.setB(a2.getB());
The above can be translated to a1.b1= a2.b2;
Now b1 will point to elements which were in b1. Since this is One to many operation, the elements will be moved from b2 to b1.
Therefore b2 will be empty.
Note: The key word here is that the change operation performed is a set and not an add

Hope my explanation helps.
 
Devender Thareja
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"set" is not the key word, as the behaviour would be different with different relationship types. The key is the relationship. A and B has one to many relationship.
That means one instance of A is related to many instances of B and each instance of B is related to exactly one instance of A.
When you say
a1.setB(a2.getB());
You are saying that all instance of B related to a2 should relate to a1 now. Since they are allowed to relate to only one instance of A, a2 will be set to empty.
The result would be different of it is many to many relationship.

Cheers!
 
Sankar Subbiramaniam
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK. Please explain why b2 is empty ?

Also what is the difference between these two statements
1) a1.setB(a2.getB());
2) a1.getB().addAll(a2.getB());
[ December 15, 2005: Message edited by: Sankar Subbiramaniam ]
 
Devender Thareja
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sankar Subbiramaniam:
OK. Please explain why b2 is empty ?

Also what is the difference between these two statements
1) a1.setB(a2.getB());
2) a1.getB().addAll(a2.getB());

[ December 15, 2005: Message edited by: Sankar Subbiramaniam ]


Ok, Sankar, I am little confused because there is no mention of AddAll in HFEJB but I will make an attempt to answer your question. Let me know if it doesn't make sense to you.
I haven't seen the spec yet. But I will make my own example here:
Let's say it's like this initially:
A a1,a2;
B b1,b2;
a1.setB(b1);
a2.setB(b2);

A and B have one to many relationship.
Once you say:
a1.setB( a2.getB() );

Now a1 is refering to bean b2. The bean b2 has replaced bean b1, hence bean b1 is now not related to anyone. Now b1 is empty?
select object(B) from B where B.A is null;

Also, since container has moved b2 from a2 to a1, hence a2 is also not related to any B bean.
select object(A) from A where A.B is empty;

Answer to your second question, (my best guess):

1) a1.setB(a2.getB()); // Replace existing B beans with new value
2) a1.getB().addAll(a2.getB()); // Append new beans to existing B beans
In option 2, a1 is related to b1 and b2 both now. And a2 is not related with any B bean.
Does it make sense?
 
Sankar Subbiramaniam
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK. Now you see the difference between set and add :-)
 
Devender Thareja
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes. But I still stick to my point. The key is the relationship which decides whether a partner in relationship is copied or moved. The set would not make existing parther null if many parters are allowed for this bean.
We both are right in our own ways.
[ December 16, 2005: Message edited by: Devender Thareja ]
 
Sankar Subbiramaniam
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following link provides the details between set operation and add operation on a managed collection (CMR collection):
excerpts from EJB2.0 spec regarding assignment operations (Mikalai Zaikin notes)

Add operation:
The methods of the java.util.Collection API for the container-managed collections used for collection-valued cmr-fields have the usual semantics, with the following exception: the add and addAll methods applied to container-managed collections in one-to-many relationships have a special semantics that is determined by the referential integrity of one-to-many relationships.

If the argument to the add method is already an element of a collection-valued relationship field of the same relationship type as the target collection (as defined by the ejb-relation and ejb-relationship-role deployment descriptor elements), it is removed from this first relationship and added, in the same transaction context, to the target relationship (i.e., it is effectively moved from one collection of the relationship type to the other). For example, if there is a one-to-many relationship between field "person" and "telephones", adding a "telephone" to a new field "person" will have the effect of removing it from its current field "person".



set operation:
The semantics of a set accessor method, when applied to a collection-valued cmr-field, is also determined by the referential integrity semantics associated with the multiplicity of the relationship. The identity of the collection object referenced by a cmr-field does not change when a set accessor method is executed.

In the case of a one-to-many relationship, if a collection of entity objects is assigned from a cmr-field of in one instance to a cmr-field of the same relationship type in another instance, the objects in the collection are effectively MOVED. The CONTENTS of the collection of the target instance are REPLACED with the contents of the collection of the source instance, but the identity of the collection object containing the instances in the relationship does not change. The source cmr-field references the same collection object as before (i.e., the identity of the collection object is preserved), but the collection is empty.

The Bean Provider can thus use the set(...) method to MOVE objects between the collections referenced by cmr-fields of the same relationship type in different instances. The set accessor method, when applied to a cmr-field in a one-to-many relationship thus has the semantics of the java.util.Collection methods clear, followed by addAll, applied to the TARGET collection; and clear, applied to the SOURCE collection. It is the responsibility of the container to transfer the contents of the collection instances in the same transaction context.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic