Online Database¶
The purpose of the Online Database (OLDB) is to allow SRTC components to store monitoring datapoints for access by external tools and systems. It should not be used to exchange data between SRTC components, such as Data Tasks. Use the Runtime Configuration Repository for this instead.
The OLDB datapoints that will be updated by a component should be created in an idempotent manner
during the initialisation activity when the Init command is received, i.e. if a needed datapoint
does not exist it should be created, otherwise the existing one be reused.
The monitoring datapoints can then be updated as needed during the remaining lifetime of the
component.
The OLDB datapoints should typically not be deleted by the component. They are cleaned up externally. It is nevertheless possible to delete such a datapoint if necessary.
Data Access¶
The API for accessing datapoints is identical to the Runtime Configuration Repository.
The only difference is that the interface class to use is the OldbIf.
The OLDB should always be accessed through an instance of OldbIf.
An instance is fetched from the Service Discovery as follows:
auto oldb = m_services.Get<OldbIf>();
For this to work, each component must have the endpoint configured in the service discovery using
the oldb_endpoint datapoint (see also section Service Discovery).
Two URI schemes are supported for oldb_endpoint:
- cii.oldb
This is for the fully fledged OLDB, e.g.
cii.oldb:///instrument/oldb.- file
For development and testing. This should point to the directory containing the YAML files for the repository on the local file system, e.g.
file:/home/eltdev/oldb.
Refer to the Data Access sub-section of Runtime Configuration Repository for details about the actual methods for creating, reading, writing, deleting and querying datapoints.
Datapoint Subscription¶
The fully fledged OLDB supports subscription to datapoints, i.e. registering callbacks for new data updates and datapoint removal notifications. The API is the same as for the Runtime Configuration Repository. Therefore, refer to that Datapoint Subscription sub-section for details.
Note
Similarly to the file based Runtime Configuration Repository, the file based OLDB implementation
does not support subscription and will throw NotImplementedException exceptions if used.
Supported Data Types¶
The same C++ data types are supported as for the Runtime Configuration Repository.
Refer to the Supported Data Types sub-section of
Runtime Configuration Repository for additional details.
However, the underlying metadata instance names used for the fully fledged OLDB implementation are
different than those used for the OLDB backed Runtime Configuration Repository implementation.
This is not the case for the file based implementation, where the same internal types are used.
As long as all access is performed through OldbIf, this difference is transparent to the end
developer.
The following is a table of the data type to internal metadata instance mapping for the fully fledged OLDB implementation:
C++ Type |
Internal Type Name |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File Format¶
The current OLDB implementation uses the same internal file format as the Runtime Configuration Repository, with the one difference that all datapoints land up in a single YAML file, rather than a YAML file per component. Refer to the File Format sub-section of Runtime Configuration Repository for further details.
Limitations and Known Issues¶
The same limitation currently apply to the OLDB repository as the Runtime Configuration Repository. Refer to the Limitations and Known Issues sub-section of Runtime Configuration Repository for further details.