Working with Inheritance

Inheritance describes how a child class inherits the characteristics of its parent class. OracleAS TopLink provides multiple methods to preserve the inheritance relationships. You can override mappings that have been specified in a superclass, or map attributes that have not been mapped at all in the superclass.

Note:

When using an aggregate descriptor in an inheritance, all the descriptors in the inheritance tree must be aggregates. Aggregate and Class descriptors cannot exist in the same inheritance tree.

Using Inheritance with EJBs

Although inheritance is a standard tool in object-oriented modeling, the current EJB specification contains only general information regarding inheritance. You should fully understand the current EJB specification before implementing inheritance.

Caution:

Use caution when employing inheritance. The next EJB specification may dictate inheritance guidelines not supported by the different servers.

Mapping Inherited Attributes in One Descriptor

If you are mapping only one class in an inheritance hierarchy, you can map attributes that it inherits from any of its superclasses.

To map attributes in one descriptor:

In the Navigator pane, select a descriptor.
Right-click the descriptor and choose Map Inherited Attributes > specific location from the pop-up menu. You can also choose Selected > Map Inherited Attributes from the menu.

Map inherited attributes to:
- Superclass
- Root minus one
- Selected class
Map the now visible attributes as though they belonged to this descriptor.

You can also do this if you have a common superclass that stores little or no persistent data. For example, if you were mapping subclasses of java.rmi.RemoteObject, each subclass could be mapped independently.

Supporting Inheritance Using One Table

Store classes with multiple levels of inheritance in a single table to optimize database access speeds.

The following diagram illustrates the Vehicle object model.

Figure 4-25 Supporting Inheritance Using One Table

Description of the illustration javainhr.gif

The entire inheritance hierarchy can share the same table, as in Figure 4-26. The FueledVehicle and NonFueledVehicle subclasses can share the same table even though FueledVehicle has some attributes that NonFueledVehicle does not. The NonFueledVehicle instances waste database resources because the database must still allocate space for the unused portion of its row. However, this approach saves on accessing time because there is no need to join to another table to get the additional FueledVehicle information.

Figure 4-26 Inheritance Using a Superclass Table with Optional Fields

Description of the illustration inhtable.gif

Figure 4-27 illustrates the OracleAS TopLink implementation of the FUELEDVHCL, CAR, and BICYCLE tables. All objects are stored in the VEHICLE table. The secondary table stores FueledVehicle, Car, and Bicycle information.

Figure 4-27 Inheritance Using Separate Tables for Each Subclass

Description of the illustration inhsepar.gif

Note:

Because NonFueledVehicle does not hold any attributes or relationships, it does not need a secondary table. For performance considerations, this design is inefficient because it requires multiple table fetching.

Supporting Inheritance Using Multiple Tables

For subclasses that require additional attributes, use multiple tables instead of a single superclass table to optimize storage space (because there are no unused fields in the database). However, this may affect performance because OracleAS TopLink must read from more than one table before it can instantiate the object. OracleAS TopLink first looks at the class indicator field to determine the class of object to create, then uses the descriptor for that class to read from the subclass tables.

Finding Subclasses

An inheritance mapping for a root class must be able to locate its subclasses by using one of the following methods:

Providing a class indicator field, which contains a key corresponding to its subclass.
Including a class extraction method, which can be implemented in Java code; this is simply a method that returns a java.lang.Class object.
Using class names directly in the class indicator field.

Providing a Class Indicator Field

Use a class indicator field in the table of the root class table to indicate which subclass should be instantiated. The indicator field should not have an associated direct mapping unless it is set to read-only.

Note:

If the indicator field is part of the primary key, define a write-only transformation mapping for the indicator field. Refer to "Working with Transformation Mappings" on page 5-9 for more information.

You can use strings or numbers as values in the class indicator field. The root class descriptor must specify how the value in the class indicator field translates into the class to be instantiated. The following table illustrates the class indicator mapping from the Vehicle class containing four entries.

Table 4-1 Class Indicator Mapping from the Vehicle Class

Key	Value
F	FueledVehicle
N	NonFueledVehicle
C	Car
B	Bicycle

When working with hierarchies more than two levels deep, the class indicator field and the class indicator mapping can be in only the root class.

Note:

All concrete classes in the hierarchy must have a defined indicator value.

Understanding Root, Branch, and Leaf Classes in an Inheritance Hierarchy

OracleAS TopLink allows three types of classes in an inheritance hierarchy:

The root class stores information about all instantiable classes in its subclass hierarchy. By default, queries performed on the root class return instances of the root class and its instantiable subclasses. However, the root class can be configured so queries on it return only instances of itself without instances of its subclasses.
Branch classes have a persistent superclass and also have subclasses. By default, queries performed on the branch class return instances of the branch class and any of its subclasses. However, as with the root class, the branch class can be configured so queries on it return only instances of itself without instances of its subclasses.
Leaf classes have a persistent superclass in the hierarchy but do not have subclasses. Queries performed on the leaf class can only return instances of the leaf class.

Specifying Primary Keys in an Inheritance Hierarchy

OracleAS TopLink assumes that all of the classes in an inheritance hierarchy have the same primary key, as set in the root descriptor. Child descriptors associated with tables that have different primary keys must define the mapping between the root primary key and the local one.

See "Specifying Multi-table Info" for more information on primary keys in an inheritance hierarchy.

Mapping Inherited Attributes in a Subclass

If you are defining the descriptor for a class that inherits attributes from another class, then you can create mappings for those attributes. If you remap an attribute that was already mapped in the superclass, then the new mapping applies to the subclass only. Any other subclasses that inherit the attribute are unaffected.

To view and map attributes inherited from a superclass:

In the Navigator pane, right-click a descriptor and choose Map Inherited Attributes > selected class from the pop-up menu or choose Selected > Map Inherited Attributes from the menu.

The mappings list now includes all the attributes from the superclass of this class.

Map any desired attributes. See "Working with Mappings" for more information.

If you leave inherited attributes unmapped, OracleAS TopLink uses the mapping (if any) from the superclass if the superclass's descriptor has been designated as the parent descriptor.

Note:

You cannot map inherited attributes on a descriptor whose superclass has no descriptor. You can select the root descriptor, but cannot map its attributes.

In order to map the project, import the superclass into the project. OracleAS TopLink Mapping Workbench creates a descriptor for the superclass. Then deactivate this descriptor or remove it from the project.