TopLink CMP Persistence Does Not Support Uni-Directional Many-To-One Relationships (Doc ID 456768.1)

Last updated on MAY 25, 2021

Applies to:

Symptoms

TopLink MW and the JDeveloper TopLink mapping dialogs do not allow to configure an uni-directional many-to-one relationship according to the EJB 2.1 specification for CMPs.

When using TopLink POJO persistence application developers typically use a OneToOneMapping on the primary side of a logical many-to-one relationship. This is not possible when using TopLink as a CMP persistence provider, because the EJB 2.1 specification requires a CMP persistence provider to enforce a strict one-to-one relationship multiplicity for a defined one-to-one relationship.

10.3.6 Semantics of Assignment for Relationships
The assignment operations for container-managed relationships have a special semantics that is determined
by the referential integrity semantics for the relationship multiplicity.
In the case of a one-to-one relationship, when the Bean Provider uses a set accessor method to assign an
object from a cmr-field in one instance to a cmr-field of the same relationship type (i.e., as defined by
the ejb-relation and ejb-relationship-role deployment descriptor elements) in another
instance, the object is effectively moved and the value of the source cmr-field is set to null in the same
transaction context. If the argument to the set accessor method is not of the same type as the cmr-field,
the container must throw the java.lang.IllegalArgumentException.
In the case of a one-to-many or many-to-many relationship, either the java.util.Collection
API or a set accessor method may be used to manipulate the contents of a collection-valued cmr-field.
These two approaches are discussed below.
...

An uni-directional many-to-one relationship is usefull, if only one or few objects should be queried and the primary object must be accessible from the detail objects, but there is no requirement to access all detail objects from the primary. There is a performance benefit to execute a query on the detail objects and to access the primary from the detail objects, because only the required detail objects would be queried and build. For the same reason it might be unwanted to offer an accessor in the primary object to it's detail objects, because this would allow an application developer to write code that queries all of the detail objects of a primary while one or few are required.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.