Reading EJB3 In Action, for OneToOne, they give the example of BillingInfo to a User.
A User may have 1 instance of BillingInfo, however they don't have to.
BillingInfo must have a User, or there's no point storing it.
So, on the User class, @OneToOne is used and on the BillingInfo class "optional=false" is used. Pg. 244, "This means that a BillingInfo object cannot exist without a related User object".
It also means, that the user's @OnetoOne has a defaulted optional flag of true, so a user can exist without BillingInfo.
Ok - happy.
Moving on to OneToMany they use the example of an Item and Bids.
An Item may have many bids.
Bids must related to an item or they make no sense.
So, on the Item class, a collection of Bids is used, and we're told that @ManyToOne's are always the owner (makes sense from a db point of view), so Item has the mappedBy element.
However, there is no way to set the optional flag, and I don't know why that is.
I would have suggested that if optional was 'false', it would mean the relationship wasn't optional, therefore if a item exists, it must have bids.
and I would have suggested that a true value would say that an Item can exist without bids.
Skipping forward to ManytoMany, it seems as if when you are referencing a collection, the optional flag disappears. I wonder if it is because you always have the relationship, but you just end up with an empty collection if (for example) there are no bids on an item. The relationship is always optional when referencing a collection?
Hope that makes sense - it's quite difficult to get your head around!
There are actually two relationships that have the optional flag:
Why there is an optional flag in these interfaces and no optional flag in the other interfaces is not described, so we can only try to figure out what the writers meant when they were writing the specs.
I think that the reason might be related to the fact that the relations are unidirectional. With an unidirectional relation it can be that an Entity can only exist when the other Entity is there. With a bidirectional interface both entities have a right to exist and at some point in time they can be related to each other.
Unidirectional: a Phone without an Owner doesn't make sense (or in other words: we aren't interested in the phones number if it is not related to a person, and we don't want to store it in the database unless the relationship is there)
Bidirectional: A Person can have an Address, an Address can have a Person, but it is also possible to have a Person without an Address and an Address can be without a Person at some point in time. So it makes sense to always allow null values in the database for the relationship attributes in this case.
Even I reached to this thread looking for the answer of the question: why no "Optional" on @OneToMany annotation.
Since I did not find answer by quick googling.. I gave it some more thought. Though the thread is a bit old but still thought to share my view for other's benefit.
My understanding is as below:
In associations like one-to-many and many-to-many, the many side entity(referenced entity) is declared as a Collection<otherSideEntity>. In case there does not exist any related instances at runtime, the collection will be empty but NOT null. Hence having Optional element for such association is not needed.
Whereas in associations like one-to-one, many-to-one, the other side(referenced entity) is a single-valued reference. So you do have a possibility of NULL value for referred entity, if the association is optional. and hence the optional element.