You can create subclasses of persistent classes in the Class Builder. These subclasses are also persistent classes, in that they inherit the persistence mapping of the superclass to the database table or tables. The Mapping Assistant in the Class Builder supports mapping inheritance. The mapping for the superclass is represented for the subclass in the Mapping Assistant but you cannot change it. Otherwise, you would be violating the polymorphism principle of inheritance (that is, that users can treat subclasses like superclasses).
When the Class Builder generates the class actors for a persistent subclass, it automatically includes the mapping information and attributes of all its superclasses. There are two ways that a subclass can inherit mapping:
In the subclass, the persistent attributes that were defined in the subclass can be mapped to separate tables, database views or structures. The general rule for multiple table mapping applies: The keys for the additional tables, database views or structures must be the same as the keys for the superclass tables, database views or structures. The key fields are therefore mapped in the superclass and the subclass. Thus additional attributes and their associated GET and SET methods are added to the subclass, without affecting the attributes and methods of the superclass. In the superclass, all persistent attributes must be mapped.
A special case of vertical mapping exists when the persistent attributes that were additionally defined in the subclass are mapped to the same tables, database views or structures as the superclass attributes. To ascertain which class a table entry belongs to, there must be a special field of the type OS_GUID in one of the tables, database views or structures. When mapping in the Mapping Assistant, this field is given the assignment type type identifier.
If a persistent superclass is abstract, you can define persistent attributes without specific mapping in it. In every direct subclass, you must specify a mapping for the persistent attributes of the superclass. The subclasses can be mapped to different tables, database views or structures. The system does not check whether or not the subclasses are mapped to different tables or structures.
The class actors of persistent classes that are in an inheritance relationship are not in a corresponding inheritance relationship. The same principle applies that a class actor only manages the objects of the corresponding classes and the subclass objects. As a result, private attributes of non-final persistent classes are not completely protected from read or write accesses. Information that is to be protected must not be stored in private attributes of non-final persistent classes.
Polymorphism in the Class Actor Methods
The methods DELETE_PERSISTENT, REFRESH_PERSISTENT, and RELEASE of the interface IF_OS_FACTORY of the class actor behave polymorphically; this mean that for a specified managed object these methods can also be called in the class actor of a (non-abstract) superclass of this object. At runtime, you can use the transferred reference to define the type of the managed object and call the appropriate class actor of the subclass.
If an additional type field (type identifier) exists in one of the tables, database views, or structures that is mapped to the root class of the inheritance hierarchy, the methods GET_PERSISTENT, DELETE_PERSISTENT, GET_PERSISTENT_BY_KEY, and GET_PERSISTENT_BY_OID of the interface IF_OS_CA_PERSISTENCY of the class actor behave polymorphically. This means that with the class actor of a (non-abstract) persistent class you can also use the key to read (business key or GUID) or delete (business key) a persistent object that belongs to a persistent subclass of the classes managed by this class actor. This is done by delegation to the class actor of the subclass, which can be ascertained at runtime using the information in the type field.
Specifying an additional type field (type identifier) ensures that the (business) key is unique in the entire inheritance hierarchy. It is therefore not possible to create a managed object with the same key as a managed object of another subclass, superclass, or the latter’s subclasses.