Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Entity bean relationship question  RSS feed

 
Edward Chen
Ranch Hand
Posts: 798
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This question really confused me. Please give me help.
------------------------------------------
4. Given the container-managed unidirectional relationship
Foo(0-1)->Bar(0-1)
/** this is one-to-one one-way relationship. that means: each Foo ojbect has one Bar object; each DIFFERENT Foo object has one DIFFERENT Bar object. Am I right?
**/
And the object relations
f1->b1
f2->b2
What will be true after the following code runs?
f2.setBar(f1.getBar()); // actually is f2.setBar(b1), am I right?
1.f1.getBar() == null
2.b2.getFoo() == null
3.b1.getBar() == null
4.none of the above
----------------------------------------------------
1.
I think, after f2.setBar(b1), the problem is both f1 and f2 refer to the SAME b1, just like two different students have ONE SAME address.
if each DIFFERENT Foo object should have one DIFFERENT Bar object, f2.setBar(b1) should throw exception.
2.
on option 2-- b2.getFoo() == null should be true. because this is one way from Foo to Bar, Bar object has no ways to know the Foo object
3.
on option 3 -- b1.getBar() == null . it confuses me. why Bar object gets itself, return "this" ? for me, it is hard to imagine in a class we set a function like this. It is better to say, b1.getBarID().
please correct me.
Thanks
Edward
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll give it a try.
First, you are mosstly correct about the relation definition. The (0,1) means that each Foo can have one Bar *or none*. It is unidirectional, which means there's no way from the Bar to its Foo.
The result of "f1.setBar(f2.getBar()) should be to *remove* the relation f1->b2 since it's a 1:1 relation. Instead of throwing an exception, the container will remove the old relation and make the new one. If it blocked you, you'd have to do
b = f1.getBar();
f1.setBar(null);
f2.setBar(b);
which would be a big PITA and is the whole point of container-managed relationships. Thus, option 1 will be the result.
As you stated, you cannot even do b2.getFoo() as there's no such method, and similarly Bar doesn't have a relation to itself, so b1.getBar() also makes no sense.
 
Edward Chen
Ranch Hand
Posts: 798
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, David, thanks for your reply.
you said "The (0,1) means that each Foo can have one Bar *or none* "; what you mean "or none"? Could you give me an example?
I think "
Foo(0-1)->Bar(0-1)
/** this is one-to-one one-way relationship. that means: each Foo ojbect has one Bar object; each DIFFERENT Foo object has one DIFFERENT Bar object.
**/
" Am I right? please tell me. Thanks.
Edward.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Edward Chen:
you said "The (0,1) means that each Foo can have one Bar *or none* "; what you mean "or none"? Could you give me an example?

Yes, an example would help. Let's say you have Users (0,1) -> (0,1) Address. This means that each User can have an Address or not -- user.getAddress() may return null. If you wanted to enforce that each User have one address (and vice versa, each Address has a User), it would be User 1 -> 1 Address.
If in the example you started with the relationship had not allowed nulls, then switching b1 from f1 to f2 would throw an exception as you cannot remove the Bar from f1 without replacing it with a different one.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!