Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Setting to null an element of the many side of a relationship

 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I've got the following scenario:

A (1) <----------> (*) B

A is in a 1:many relationship with B

And I've got:

a1 -------> b1
b2
bn

What happens if I write:

bn.setA(null)

Will (a1 == (bn.getA()) ???
 
Dan T
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I've got the following scenario:

A (1) <----------> (*) B

A is in a 1:many relationship with B

And I've got:

a1 -------> b1
b2
bn

What happens if I write:

bn.setA(null)

Will (a1 == (bn.getA()) ???


Im not too strong on this, but I'll give it a try.

I dont think bn.setA(null) will change anything. From my understanding, what you are trying to say is "bn is now going to have a reference to A. Please set it to null". It still doesnt change the fact that b1 is still in relationship with a1. However, if you did this: bn.setA(b1.getA()), now
a1.getB().equals(bn) returns true.
 
Dan T
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From spec 10.3.8, you will actually get a IllegalStateException if you assign a null in a cmr relation that takes in collection as a field.

So if we did a a1.setB(null), we would have got an exception
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ryan Wong:
From spec 10.3.8, you will actually get a IllegalStateException if you assign a null in a cmr relation that takes in collection as a field.



Can you quote where exactly in 10.3.8 you may read that the Container will throw an IllegalStateException? I haven't found it.

And following the specs, it seems that nothing will happen, but I am not sure, that why I posted this question.

From specs 10.3.7.3:

Before change:
Collection b1 = a1.getB();
Collection b2 = a2.getB();
B b11, b12, ... , b1n; // members of b1
B b21, b22, ... , b2m; // members of b2

Change:
a1.setB(a2.getB());
Expected result:
(a2.getB().isEmpty()) &&
(b2.isEmpty()) &&
(b1 == a1.getB()) &&
(b2 == a2.getB()) &&
(a1.getB().contains(b21)) &&
(a1.getB().contains(b22)) && ... &&
(a1.getB().contains(b2m)) &&
(b11.getA() == null) &&
(b12.getA() == null) && ... &&
(b1n.getA() == null) &&
(a1.isIdentical(b21.getA())) &&
(a1.isIdentical(b22.getA())) && ...&&
(a1.isIdentical(b2m.getA()))

[That's all right so far...]

Change:
b2m.setA(b1n.getA());

Expected result:
(b1.contains(b11)) &&
(b1.contains(b12)) && ... &&
(b1.contains(b1n)) &&
(b1.contains(b2m)) && ----> This is where the magic happens. If you look at the expected results during the first change, (b1n.getA() == null), therefore the above change is equivalent to say: b2m.setA(null);
But as you can see, b1.contains(b2m) is still true, result of the first change, therefore nothing had happened.
(b2.contains(b21)) &&
(b2.contains(b22)) && ... &&
(b2.contains(b2m_1)) &&
(a1.isIdentical(b11.getA())) &&
(a1.isIdentical(b12.getA())) && ... &&
(a1.isIdentical(b1n.getA())) &&
(a2.isIdentical(b21.getA())) &&
(a2.isIdentical(b22.getA())) && ... &&
(a2.isIdentical(b2m_1.getA())) &&
(a1.isIdentical(b2m.getA()))



The only cases when the Container throws an IllegalStateException, in 10.3.8. is when the client tries to modified a CMR-valued field using the Collection API or java.util.Iterator in a transaction context other than the one that originally generated the cmr-valued field.
 
Dan T
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry about that

Its java.lang.IllegalArguementException

I forgot what i was typing
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic