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 databasesUser_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 chainShutdown_After_Last
(boolean) - when operating in the asynchronous mode, should we emit theShut_Down
device event after the last step?
Database writer
Generate_Primary_Keys
(boolean) - if set totrue
, it creates a new time segment (with its own identifier) for every incoming segment; if set tofalse
, it uses the segment ID from the device eventStore_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
.