Base type wizard

In order to provide a new base type, the base type wizard might be called from the base type list, which can be activated by clicking the Base Types tab on the Members tab for the selected data type.

The base type wizard cannot be used for updating base type properties, which has to be done directly in the base type editor form right of the list.

In contrast to most programming languages, the base type in ODABA is a member, which might get a member name different from the data type name. It is, however, suggested to use the data type name as member name as long as the selected data type does not inherit twice from the same data type. A list of data types defined within the project is shown in the drop list.

By default, the base type member name is used as data type for the base type, but one may also select a data type from the drop list or use enhanced find by pressing the Find button. This allows selecting a data type defined in other projects or a system data type. When the data type for the base type has not yet been defined, one may enter the new data type name in the field and press the New button. In this case, a sub wizard for defining new data type pops up (Data Type Wizard), which is described in chapter Data Type Wizard. For viewing the type definition for the selected type, the Details button might be used.

When an extent has been defined for the selected type, the wizard will request an extent definition in the next step.

In order to define an exclusive base type instance, which becomes a physical part of the specialized instance, the Superset field has to be cleared. before continuing with Next.

In order to define shared base instances, i.e. base type instances that are shared by different specializations, a base collection (extent) has to be defined for the base type, which contains the base type instances. Usually, shared base type refer to extents (list entries not starting with dot) rather than to local extents (dot entries in the list). When a superset has been defined, the next step requests the definition of an inverse relationship.

The inverse relationship becomes member of the base type. When auto init is switched on (default), the member properties for the inverse are generated correctly, i.e. one only need to enter a name for the inverse relationship (or select a candidate from the drop list) and click next for continue. In order not to create the inverse relationship automatically, the auto init option should be switched off (not suggested). In order to define and browse the new relationship explicitly, the Define button might be pressed, which allows e.g. correcting the cardinality (dimension), which is initialized wit 0 (undefined) but should be set to 1, when only one specialized instance for the given type can be created. E.g. when a person may act as employee in any number of companies, the cardinality should be set to 0, since in this case any number of employee instances might be derived from the same person. When, however, the person is allowed to act as employee in only one company, i.e. one employee per person cab be created, the cardinality should be set to 1.

While creating an inverse relationship, several messages may appear in the ClassEditor output area informing you, that the base type instance has been modified. Since the wizard runs in a transaction, these modifications are not stored, when the wizard is canceled.

The Next step leads to the final confirmation of changes:

After confirming the wizard action with Finish, changes made on the current data type (and on its base type) are stored to the resource database. For updated complex data types the ready and checked mark are reset and the data types are displayed orange in the class tree instead of green. Updated data types need to be checked before being used in the application. One may use the check button above the member list for checking the selected data type.