Defining extension properties
Typically, extension properties are defined by calling creating object instances in one of the extension property extents in the database or dictionary ( SDB_Attribute , SDB_Reference or SDB_Relationship ). Extension properties defined in the dictionary are considered as sort of default property extensions and might be referenced in each database application.
Besides defining extension properties in a dictionary, one may create ad hoc extension properties in the database. When defining a database extension property with a name that has already be defined as dictionary extension property, the extension property definition in the database will overload the dictionary property definition.
The list of extension properties in the database might be extended by the application, i.e. the user may create new extension properties from within the application. There are different ways of defining extension properties:
- Using ODL
- Using the extension property dialog provided with the ODABA GUI framework ( ClassEditor )
- Defining extension properties in a program or OSI script
Defining extension properties within a program allows creating extension properties on demand from within an application.
In order to provide extension property definitions by means of ODL one has to provide an ODL script similar to the one in the example below. One may import extension property definitions into a database as well as into a dictionary (resource database).
For extending the set of extension properties, UPDATE should precede the EXTENSIONS keyword. This will update existing extension property definitions and create new definitions for those that have not yet been defined in the dictionary or database.
In order to redefine extension properties completely, NEW should precede the EXTENSIONS keyword (deleting existing definitions before). Since internal identifiers are created when adding a new extension property to the database/dictionary, one should not remove extension property definitions after data has been stored.
Extension properties in a dictionary are protected against any further update as soon as the production state has been activated for the dictionary. Extension properties created within the application database should never be changed after being defined. This is, however, not checked yet by ODABA.
NEW EXTENSIONS {
ATTRIBUTE {
PROTECTED STRING(7) ext_char ;
PROTECTED INT(10,0) ext_number ;
PROTECTED REAL ext_real ;
PROTECTED DATETIME ext_timestamp ;
};
REFERENCE {
PROTECTED STRING(1000) OWNER ext_memo [1];
PROTECTED __XOBJECT OWNER ext_object [1]
ORDERED_BY ( __IDENTITY UNIQUE );
};
RELATIONSHIP {
PROTECTED __XOBJECT UPDATE ext_inverse [1]
INVERSE ext_relation
BASED_ON __XOBJECT
ORDERED_BY ( __IDENTITY UNIQUE );
PROTECTED __XOBJECT UPDATE SECONDARY ext_relation [1]
INVERSE ext_inverse
BASED_ON __XOBJECT
ORDERED_BY ( __IDENTITY UNIQUE );
};
};
When importing an extension schema from an ODL file that contains more schema information than the extension schema, all schema information will be imported. Hence, one might use the function for importing more complex schema definitions, too.
A more comfortable way of defining extension properties is the property dialog provided by the ODE class editor. The extension dialog is a standard dialog, which may also be called in any application for creating extension properties in a database.
In order to open the extension property dialog select Objects/Extension Properties from the ClassEditor or Designer application:
The property definition dialog allows creating attributes, references and relationship definitions, but also importing or exporting extension schemata from/to ODL.
When using the create buttons, the corresponding attribute, reference or relationship wizard pops up in order to support creating new extension property definitions. Extension property definition for the selected extension property is displayed on the right side. Definition forms depend on the type of extension property selected (attribute, reference or relationship).
Check functions are provided for checking all defined or selected extension properties. Errors found during check process are displayed in the applications output area. One should never use unchecked property schemata.
In order to exchange extension schemata between databases, one may use the export and import functions. The export function writes an ODL schema definition to an external file. The import function imports extension property definitions provided in an ODL file.
In order to increase flexibility, one may define extension properties at run-time from within a program. Extension properties defined in an application program should always be stored in the database. When running databases with multiple object spaces, extension property definitions have to be stored in the root object space (database).
Details for defining attributes, references or relationships one may find in the ODABA data model reference . The extension schema defined in a database might be extended but not updated, since data might already be stored for existing property extensions. When creating property extensions at run-time, the application is responsible for performing proper checks for the definitions provided.
One might also use the extension dialog or something similar to allow the application user entering extension property definitions.
After changing the extension schema for a database, this has to be reloaded by calling Database ::extensionsLoad() in order to activate new extension properties
... fragment ( Database &database ) {
Property xAttributes(database,"SDB_Attribute",Write); // extension attributes
Property xReferences(database,"SDB_Reference",Write); // extension references
Property xRelationships(database,"SDB_Relationship",Write); // extension relationship
xAttributes.insert("ext1"); // create new extension attribute ext1
xAttribute.value("ddetype") = "INT"; // set data type to int
... set other property attributes as described for data type SDB_Attribute
... create reference and relationships in similar way
database.extensionsLoad();
}
In the current version, there is no check implemented for preventing extension properties that have already got property extensions (data) from being updated in the database extension schema. Such changes may, however, cause damages on property extension instances stored so far.