Release Notes for CDI

Nuno Fiuza de Barros

May 30, 2005

1 Introduction

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.

CDI is composed by two applications which role shall be explained in more detail:

2 Backend specic features

Sice the connection string pattern is dierent for both implementations of the CoditionsDB, it was not possible to have a single environment variable to dene the connection string.

Therefore, the connection string are specied by dierent environment variables (see table 1):





Lisbon CondDBTDAQ_CONDDB_PROFILEatlobk02.cern.ch:test_play_daq:conditions:conditions
COOL TDAQ_COOL_PROFILE oracle://devdb10;schema=onlcool;user=onlcool;password=ora10cool;dbname=CDI_TEST




Table 1: Environment variables to to specify the connection parameters

Furthermore, COOL has a strong dependency in a couple of environment variables, some of which need to be dened. The mandatory environment variables that need to be dened are shown in table 2






SEAL_PLUGINS Must point to all folders containing plugin registries. Usually this folder is named modules and is located under lib folder.
SEAL_KEEP_MODULESMust be dened to true.
TNS_ADMIN must point to the location of Oracle connection denition les. Under afs the value is set at login time and default value is "/afs/project/oracle/admin"





Table 2: Environment variables needed to run the COOL based CDI

3 Implementation details

Although there was a large eort to miniimize the dierences between implementations in order to have a well dened 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.

3.1 The Lisbon API

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 dened, 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:




ISType CondDBTable type




Boolean cdbBool
S16 cdbInt
U16 cdbInt
S32 cdbLongLong
U32 cdbLongLong
Float cdbFloat
Double cdbDouble
S8 cdbString
U8 cdbString
String cdbString
Date cdbLongLong
Time cdbLongLong


Boolean cdbArrayBool
S16 cdbArrayInt
U16 cdbArrayInt
S32 cdbArrayLongLong
U32 cdbArrayLongLong
Float cdbArrayFloat
Double cdbArrayDouble
S8 cdbArrayString
U8 cdbArrayString
String cdbArrayString
Date cdbArrayLongLong
Time cdbArrayLongLong





Table 3: Mapping from the ISType to the data types in CondDBTable. The second half of the table denes the mapping of arrays.

With these available data types, the Lisbon based CDI allows to convert any kind of object from IS to a CondDBTable type.

3.2 COOL

COOL based CDI was developed in a way that would provide the maximum compatibility with the already existing features, making the dierences transparent to the user.

However there a couple of dierences, 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 AttributeListSpecication, 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 dierences 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:




ISType Attribute




Boolean bool
S16 int
U16 unsigned int
S32 long
U32 unsigned long
Float oat
Double double
S8 int
U8 unsigned int
String string
Date unsigned long
Time unsigned long





Table 4: Mapping from the ISType to the data types in the AttributeList. Since there is no support to vectors, there is no mapping for arrays.

4 Future tasks