Documentation

This page hosts the documentation of the SmartCGMS software architecture and all of its components.

The documentation is being updated to acommodate the recent improvements. Please, be patient, we are working on it...


Database filters

Currently, there are two filters for database interfacing - the database reader and writer. Both are independent on a specific database management system, however, there is a strong need for a SQL-based one. The specific database connector is implemented separately and is later injected through the db::IDb_Sink inspection interface. The specific driver is selected by the configuration parameter, which is passed directly to the connector.

Configuration

Common options

  • Host (string) - database daemon host
    • empty for file-based databases like SQLite
  • Port (integer) - database daemon port
    • ignored for file-based databases like SQLite
  • Provider (string) - a specifier of a database driver, fully dependent on the database connector implementation
    • for example, when using the Qt framework, one may use QPSQL for PostgreSQL, QSQLITE for SQLite3 and more
  • Name (string) - the name of the database, or database file path for file-based databases
  • User_Name (string) - username for database connection
    • empty for file-based databases like SQLite
  • Password (string) - password for database connection
    • empty for file-based databases like SQLite

Database reader

  • Time_Segment_Id (integer array) - time segments from database, that will be loaded and sent through the chain
  • Shutdown_After_Last (boolean) - when operating in the asynchronous mode, should we emit the Shut_Down device event after the last step?

Database writer

  • Generate_Primary_Keys (boolean) - if set to true, it creates a new time segment (with its own identifier) for every incoming segment; if set to false, it uses the segment ID from the device event
  • Store_Data (boolean) - should the filter store signal levels to the database?
  • Store_Parameters (boolean) - should the filter store signal/model parameters to the database?
  • Subject_Id (integer) - identifier of a subject to store data for
    • for an existing subject, use a valid number greater than zero
    • to create a new subject, use the value New_Subject_Identifier (-1)
    • to use an anonymous subject, use the value db::Anonymous_Subject_Identifier (-2)

Supported interfaces

  • db::IDb_Sink

General function

Database reader

The database reader is a rather simple entity. It loads all the values of all requested segments (Time_Segment_Id) and sends them through the filter chain. A beginning of every requested segment is marked with the Time_Segment_Start device event (device time matches the recorded time of the first level), and every end by Time_Segment_End (device time matches the recorded time of the last level). If there are parameters stored for the segment, it is emitted as a device event right after the segment start marker.

The filter starts a new thread to read from database and emit events through the chain. The database connection is established in this thread to comply with the general requirement of such software models.

When a Warm_Reset device event is received, the database reader is restarted and sends all the events again.

Database writer

The database writer stores the contents of configured device events to store them into database. If the Store_Data parameter is set to true, it stores the signal levels contained in the Level and Masked_Level device events. If the Store_Parameters parameter is set to true, it stores the model parameters contained in the Parameters device events.

The values are stored into memory first, and are flushed to the database upon the Time_Segment_End device event, or when the filter operation is terminated by the Shut_Down device event.

Depending on the subject selection, it either stores values by an existing subject (a valid existing subject or db::Anonymous_Subject_Identifier (-2)), or creates a new one (New_Subject_Identifier (-1)). The anonymous subject always have the database ID set to 1 by a convention. The purpose of the anonymous subject is to group every time segment, that does not belong to a specific subject, or the original subject is not known.

The Generate_Primary_Keys signals the database writer, if it should create a new primary key for every time segment, or it should rather use the ID that came in the device event. This parameter might be useful, when working with already stored segments to obtain a model parameters - then, usually, the Store_Parameters is set to true and Store_Data to false.