Using transient Attributes

Transient attributes are usually attributes properties in persistent instances, which are not stored. Of course, each property or value handle referring to a transient attribute ( e.g. Value(5)) is transient as well, but in this case it becomes clear, that the application program is responsible for the property state.

Transient attributes defined in persistent instances (as the age attribute in the Person structure of the Sample database) provide more complex features. Since the age value probably changes from person instance to person instance, it has to be reevaluated when reading new instances.

Typically, transient attributes are initialized by calling an OSI function (which may pass control to a C++ function). This is an optimal way, since transient attributes are evaluated, when being accessed, only. In some cases, it might be more comfortable to evaluate transient attributes on different application or business layers (type context class).

When the rule is simple as for the age property one may also provide an OSI function inline code for initializing the value. When defining transient properties in ClassEditor, the data source has to refer to the property name, since data sources for different purposes may be defined for a property. The initialization code is called, when accessing the attribute via Value functions (e.g. toString() ). This does not work at all, when using typed property handles and accessing the age via C++ class member names, since this is an uncontrolled access and the initialization is, for performance reasons, not called when reading the instance, but when accessing the property, only.

The rule for calculating transient properties can be defined in the source for the transient attributes (assigned value or sources). An assigned value in ODL is considered as source, when it is not a constant (but an expression) Sometimes, evaluating transient properties from source definition might be time consuming (e.g. calculating the total income for a person and all its children and grand children etc.). Thus, transient attributes should be evaluated just in time and only, when being requested.

When no source and no event handler has been defined, transient attributes are initialized, when selecting or reading a new instance ( get() , next() etc). When selecting an instance, the transient attribute is set to the default value according to the type or to the value which has been assigned as constant initialization value in the data model (assigned value or initial value).

One may evaluate transient attributes within the application program, whenever required, i.e. the person's age could be evaluated after reading a person instance. In this case, the application developer has to be aware, that each time before accessing the age it needs to be evaluated. This works fine, as long as there is one and only one place in the application, where this information is requested. In this case, it is a reasonable way to solve the problem.

When the application becomes more complex, may also write a function calculating and returning the value, in which case no transient attribute is required. The advantage of transient attributes, however, is that the business layer (type or property context class) may update transient attributes in a more optimal way.

Since the application layer usually does not care about initializing transient attributes, this job should be performed by the business layer. When initialization of transient attributes is implemented on the business layer, the typical way of handling initialization is in the read event handler (e.g. doAfterRead() handler in a type context class for Person ). In this case, the application considers the transient attribute as any other attribute in the structure instance.

In some cases, transient attributes need to be recalculates in case of modify or store events (the age must be recalculated, when the birth date changes). When the evaluation rule for the transient attribute becomes more complex, it might become necessary, to recalculate the attribute, whenever an operand value referred to in the rule, changes.

The big deal with transient properties is, that it reduces redundancy in the database. Since transient properties are calculated, when being accessed, one can be sure, that the values are correct.

In some cases, evaluation of transient properties may become a performance problem. In this case, one may turn transient attributes into a persistent ones, which are updated only, when one of the evaluation operands changes but not any more, when reading the instance. This performs much better, when the application uses many read and less write access. Another advantage is, that updates on a persistent field generate an instance updated event, which allows other applications to react on a modification in the derived field. This is not the case, when using transient attributes, since updating transient attributes generates application events, only, which are not sent to other applications. Moreover, modifying transient attributes does not alter the instance modification count. Thus, other applications are not able at all to recognize updates on the instance.