The main goal for CDI is to store run parameters into the Conditions Database. In a more general way, it is possible to store any kind of data published into the information service (IS), being this information mapped into a relational table in the Conditions Database.
Originally, CDI was developed to write data into the Lisbon Implementation of the Conditions Database, mapping the data published in the IS to the CondDB specic object, the CondDBTable, being then stored in the database itself using the Lisbon Implementation API.
Currently, as the Lisbon API is being discontinued to be replaced by COOL, CDI must follow the changes to cope with the new technology requirements.
For this release a couple of changes have been implemented in the CDI which are described as follows:
The main goal of this new release of the CDI was to update the version of COOL which COOL based CDI uses. As COOL is still in a very initial stage of its development, very often comes a new release with improvements like performance and bug correction.
As sometimes the API and database schema can change, the update of the dependencies versions implies an update in the code. The new release of COOL (COOL_1_2_0) implements a couple of new features, but mainly provides bug fixing.
Together with the COOL version, it's dependencies are also updated, like the case of POOL and SEAL.
In this release, thare are a couple of updates that were inherited from the experience of the Large Scale Tests. A set of automated tests were developed, which were added to the package. These tests allow to check in an automated way if the CDI is working properly.
Together with the tests, a script to set up the environment needed by COOL based CDI was also added. If the user intends to use the CDI from the setup_daq script, this script is not needed, as there is a n object in the configuration database to set up the dependencies of the CDI, but if the user intends to use the CDI out of setup_daq this script might prove useful.
In COOL based CDI was implemented a mechanism to check if all the mandatory environment variables are set. In case there aren't CDI interrupts the execussion writting an error message explaining which variable was not set and giving hints for the value that it must have.
Due to the user feedback stating that the CDI was too much verbose, there were some changes in the verbosity level, as well. By default the CDI is completely silent, except for error messages and a message for each time an object is stored.
However, the users can still decide the verbosity level which they want. For more details please see cdi_daq --help .
The mapping of data types was improved, making full use of the SEAL available data types. In particular, to map earlier not available data types, like long long int. In table 1 is specified the new mapping of data types.
ISTypes | pool::Attribute (type_name) | pool::Attribute (type_info) |
---|---|---|
Boolean | bool | bool |
S16 | short | short |
U16 | unsigned short | unsigned short |
S32 | long | long |
U32 | unsigned long | unsigned long |
Float | float | float |
Double | double | double |
S8 | short | short |
U8 | unsigned short | unsigned short |
String | string | std::string |
Date | unsigned long long | seal::IntBits<64>::ULeast |
Time | unsigned long long | seal::IntBits<64>::ULeast |
Although the data type mapping has improved, it is not still possible to store arrays using the COOL based CDI, as these are ot supported by COOL.
Functionality of the packages may not be the best for tag i686-slc3-icc8-opt.
The COOL based CDI may provide problems for update frequecies higher than ~1kHz.
There might be problems is the user subscribes for an object containing arrays, as these are supported in the Lisbon based CDI.