Working with Aggregate Object Mappings

Two objects are related by aggregation if there is a strict one-to-one relationship between the objects, and all the attributes of the second object can be retrieved from the same table(s) as the owning object. This means that if the source (parent) object exists, then the target (child or owned) object must also exist, as illustrated in Figure 6-7.

Aggregate objects are privately owned and should not be shared or referenced by other objects.

To implement an aggregate object mapping:

• The descriptor of the target class must declare itself to be an aggregate object. Because all its information comes from its parent's table(s), the target descriptor does not have a specific table associated with it. You must, however, choose one or more candidate table(s) from which you can use fields in mapping the target. In the example above, you could choose the EMPLOYEE table so that the START_DATE and END_DATE fields are available during mapping.

• The descriptor of the source class must add an aggregate object mapping that specifies the target class. In the example above, the Employee class has an attribute called employPeriod that would be mapped as an aggregate object mapping with Period as the reference class. The source class must ensure that its table has fields that correspond to the field names registered with the target class.

• If a source object has a null target reference, OracleAS TopLink writes NULLs to the aggregate database fields. When the source is read from the database, it can handle this null target in one of two ways:

  • Create an instance of the object with all its attributes equal to null.

  • Put a null reference in the source object without instantiating a target. (This is the default method of handling null targets.)

Target objects can also have multiple sources, hence the need to choose a candidate table during its mapping. This allows different source types to store the same target information within their tables. Each source class must have table fields that correspond to the field names registered with the target class. If one of the source tables has different field names than the names registered with the target class, the source class must translate the field names.

In Figure 6-8:

• The Period class has a direct-to-field mapping between startDate and START_DATE.

• The Employee class can use the Period class as a normal aggregate to write to its START_DATE column.

• The PROJECT table does not have a field called START_DATE, so the Project descriptor must provide a field translation on its aggregate object mapping from START_DATE to S_DATE. (If the PROJECT table had a START_DATE column, this field translation would be unnecessary.)

Aggregate target classes not shared among multiple source classes can have any type of mapping, including other aggregate object mappings.

Aggregate target classes shared with multiple source classes cannot have one-to-many or many-to-many mappings.

Other classes cannot reference the aggregate target with one-to-one, one-to-many, or many-to-many mappings. If the aggregate target has a one-to-many relationship with another class, the other class must provide a one-to-one relationship back to the aggregate's parent class, instead of the aggregate child. This is because the source class contains the table and primary key information of the aggregate.

Aggregate descriptors can make use of inheritance. The subclasses must also be declared as aggregate and be contained in the source's table. See "Working with Inheritance" on page 4-39 for more information.