Documentation:Parent, Own, and Child Table Mapping

Parent, Own, and Child Table Mapping

This page was created by Wikiadmin on 2026-07-29. Last edited by Wikiadmin on 2026-07-29.

You can choose how inheritance is stored in an SQL database when you use persistence mapping, including whether a superclass has its own table or whether its attributes are stored in child tables.

Table mapping and inheritance

An inheritance hierarchy has a parent class (superclass) and one or more child classes (subclasses). The mapping choice determines which SQL tables contain the attributes declared on each class.

For example, consider these classes:

Person has FirstName, LastName, and Sex.
Adult inherits Person and adds Profession.
Child inherits Person and adds FavoriteColor.

The default approach is that each class has its own table. In this example, Person, Adult, and Child each have a table. To load an Adult, MDriven combines the Person row with the Adult row.

A relationship is stored as an ID column. For example, if a Person belongs to a Family, the Person table contains a FamilyID column that identifies the related Family row.

Watch a class-to-SQL mapping walkthrough.

Parent, own, and child table placement

The following terms describe where attributes in an inheritance hierarchy are stored.

Placement	Where attributes are stored	Example
Parent table	The parent class has its own table. Child-specific attributes are stored in child tables, and MDriven combines the parent and child rows when it loads a child object.	`Person` stores `FirstName`, while `Adult` stores `Profession`.
Own table	A class has a table for its own mapping. This is the default behavior for classes.	`Class2`, with no special primary-key configuration, receives its own `Class2` table and default `Class2ID` key column.
Child mapped	A superclass does not receive a table of its own. Its attributes are copied into the tables of inheriting child classes.	An abstract `RootClass` with `CreateTime` and `ChangeTime` causes both columns to appear in each mapped child table.

When to child map a superclass

Child map a default superclass when it supplies common attributes to many classes and you do not want a separate table for that superclass.

For example, a package can use an abstract TheDefaultSuperClass containing CreateTime and ChangeTime. With child mapping, a concrete Class1 table contains its own Attribute1 plus CreateTime and ChangeTime. The database does not contain a table for TheDefaultSuperClass.

This avoids making database queries join a central superclass table to each child table for inherited data. The superclass remains part of the object model and type hierarchy in memory; the choice affects SQL storage.

Configure child mapping for a default superclass

Use a DefaultORMappingBuilder in the Persistence Mapper Package (PMP) to control the generated object-relational mapping.

In MDriven Designer, open your PMP designer.
Add a DefaultORMappingBuilder component.
Set the PersistenceMapper component's NewMappingProvider to the DefaultORMappingBuilder.
Set RunTimeMappingProvider to the same DefaultORMappingBuilder.
Set ChildMapRootClass on the DefaultORMappingBuilder to the default superclass that you want to child map.
Generate code and select Build All.
Switch to PMP view, select Validate Model, and then select Generate default mapping XML if you need to inspect the generated mapping.

NewMappingProvider describes the mapping expected after database evolution. RunTimeMappingProvider supplies the mapping used while the application runs. OldMappingProvider describes the mapping currently in the database and is used when MDriven compares the current and new mappings during evolution.

Configure mapping on an ordinary class

You can configure object-relational mapping for a class that is not the default superclass. If the class mapping property is not visible in MDriven Designer, set the package's OrMappingConfigMode setting.

Use this when a specific class needs mapping behavior that differs from the package default. For example, you may expose the mapping configuration for Class1 while retaining child mapping for TheDefaultSuperClass.

Key and foreign-key column names

The DefaultORMappingBuilder also controls generated column naming. By default, an ID column is named Eco_Id. You can instead use <TableName>ID, which produces names such as Class1ID and Class2ID.

You can also append ID to generated foreign-key names. For example, the association from Class2 to Class1 becomes Class1ID. This naming pattern makes joinable identity columns recognizable in the database.

Limits and considerations

These settings apply to SQL database persistence. They do not apply to XmlPersistenceMappers or MDrivenServer. MDrivenServer uses the described settings as defaults.
Normally, you do not need to generate default mapping XML. During database evolution, MDriven generates the mapping and stores it in the database for later comparison.
An abstract child-mapped class does not produce a table. In the generated mapping example, both Class3 and TheDefaultSuperClass have no database table because they are abstract and child mapped.

Contents