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 speci c 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.
CDI is composed by two applications which role shall be explained in more detail:
The cdi_daq is the main application of the CDI package. This application is responsible to connect to the IS server, subscribe for the default objects (RunParams.RunParams) and load the plugin associated with the backend chosen by the user each time a callback is sent from the IS.
This application has a couple of parameters that can be speci ed by the user which are described below (between parentesis is the abbreviation os the parameter that can also be used):
The cdi_set_conditions is an auxuliary application that allows the user to subscribe for aditional objects, besides RunParams.RunParams.
This application has no dependecy on the backend, for which is remains unchanged from the previous versions of CDI.
This application receives as input a list of IS objects, separated by space, in the form MyServer.MyObject having also the following parameters:
Sice the connection string pattern is di erent for both implementations of the CoditionsDB, it was not possible to have a single environment variable to de ne the connection string.
Therefore, the connection string are speci ed by di erent environment variables (see table 1):
|
Furthermore, COOL has a strong dependency in a couple of environment variables, some of which need to be de ned. The mandatory environment variables that need to be de ned are shown in table 2
|
Although there was a large e ort to miniimize the di erences between implementations in order to have a well de ned set of features for the CDI, there are some details that are completely dependent on the backend choosed.
Some details about each implementation are given below.
The Lisbon API functionalities are the same as in previous versions of the CDI. Each subscribed object is sent to the handle, that generates a folder name based in the release.
With the folder name de ned, the handle checks if there is some object of this type already stored in the database. If there is it retrieves the object structure from the database in a form of an empty CondDBTable with the schema initialized. FInally the handle proceeds to ll the CondDBTable fetched with the data retireved from IS. In case that there is no object in the database, the CDI fetched the ISInfoDocument associated with this object and generates the CondDBTable proceeding then to ll it with the data.
the object from the IS, lled a CondDBTable with the structure of the object and posteriorly lled the CondDBTable with data applying the IOV and storing it to the database.
The Lisbon API used a mapping to convert ISType's to CondDBTable types. The CondDBtable supports primitive types like int, bool and oat and arrays of these types. In table 3 one can see the map between ISType's and CondDBTable types:
|
With these available data types, the Lisbon based CDI allows to convert any kind of object from IS to a CondDBTable type.
COOL based CDI was developed in a way that would provide the maximum compatibility with the already existing features, making the di erences transparent to the user.
However there a couple of di erences, that was not possible to make transparent. One As the Lisbon implementation maps the data into a CondDBTable, COOL maps the ISInfo schema into an AttributeListSpeci cation, which is used to create an AttributeList. This one is the object that will hold the data and will be used to store data into the database.
One of the main di erences in functionality from COOL to Lisbon API is the support for storage of arrays. For the moment COOL does not support arraay storage, which is noot foreseens for the next times.
In table 4 one can see the mapping from the ISType's into AttributeList Attributes:
|