Adding Conditions Objects - A user experience

Preliminaries

The work described here is based on the excellent tutorials found in the Software Guides: Offline Conditions database Page. I am not an expert on the topic. However, rather than repeating what is contained in those pages, I wanted to describe my experience in adding conditions objects to my CMSSW application. This somehow updates the examples provided in the official tutorials.

Create and Register your Conditions Object

A good place to start is this page: Conditions System layout and How to create conditions objects. It gives enough information to start with.

In my case I have two kinds of conditions objects: RBCBoardSpecs and TTUBoardSpecs. I designed the corresponding C++ classes and went through all the steps given in the tutorial. Some observations:

  • Instead of checking out all the CondFormats package, I did a cvs co of CondFormats/RPCObjects and CondFormats/DataRecords
  • Since my two objects belong to the already existing CondFormats/RPCObjects, I did not need to modify any of the BuildFile(s) present in those packages

In summary, the following table shows the files added or modified and their location:

file path type
RPCTechTriggerConfig.h CondFormats/RPCObjects/interface A
RBCBoardSpecs.h CondFormats/RPCObjects/interface A
TTUBoardSpecs.h CondFormats/RPCObjects/interface A
RBCBoardSpecs.cc CondFormats/RPCObjects/src A
TTUBoardSpecs.cc CondFormats/RPCObjects/src A
T_EventSetup_RBCBoardSpecs.cc CondFormats/RPCObjects/src A
T_EventSetup_TTUBoardSpecs.cc CondFormats/RPCObjects/src A
classes_def.xml CondFormats/RPCObjects/src M
classes.h CondFormats/RPCObjects/src M
RBCBoardSpecsRcd.h CondFormats/DataRecord/interface A
RBCBoardSpecsRcd.cc CondFormats/DataRecord/src A
TTUBoardSpecsRcd.h CondFormats/DataRecord/interface A
TTUBoardSpecsRcd.cc CondFormats/DataRecord/src A
plugin.cc CondCore/RPCPlugins/src M

Compilation worked well and, as suggested, the following test produces the wanted results:

<lxplus242> EdmPluginDump | grep "RBCBoard" 
  LCGReflex/RBCBoardSpecs
  RBCBoardSpecsRcd@RBCBoardSpecs@Proxy
<lxplus242> EdmPluginDump | grep "TTUBoard"
  LCGReflex/TTUBoardSpecs
  TTUBoardSpecsRcd@TTUBoardSpecs@Proxy
<lxplus242> 

Creating and using a CondMaker to write your object to a test database

We have created and registered our conditions objects so they are available through the EventSetup service. In this step we make sure that EventSetup picks up our conditions objects at runtime and that it is able to use them in your application. But first we have to create what in the documentation is referred to as a "condition maker". This is a EDAnalizer kind of application that will talk to a selected test database via POOL and write a schema. I followed instructions from these pages:

There is no difficulty writing the analyzer. However the documentation does not provide the "pythonic" configuration files. You can have a look to my code and working configuration files:

The configuration file tells cmsRun to write a sqlite database called "myrbcconfig.db" using the PoolDBOutputService Service. Using the "sqlitebrowser" (does not come with Scientific Linux), I checked that my C++ objects were correctly converted into tables:

sqlitebrowser-myrbconfig.db-view.jpeg

Seems to work! Some observations:

  • A primary key is created by default: "ID". The variable I had for that purpose "m_pkey" was not used. Might want to replace it or change it.
  • Fields will contain either data you add in your maker application or the values given in the default constructor of your objects.

Reading the condition data from the test database

For this part, I followed instructions on this two pages:

The test is done calling the EventSetupRecordDataGetter, which is a filter and tells us if it finds or not the objects we want. This time we use the PoolDBESSource Service. This is the configuration file I wrote:

  • test_sqlite_get_cfg.py.txt: configuration file for testing the RPCTTConfMaker: it reads a sqlite file and looks for the conditions objects.

When I run over the configuration, I obtain the wanted results: the two objects seem to be available to EventSetup:

%MSG-s DataGetter:  EventSetupRecordDataGetter:get 14-Dec-2008 13:46:06 CET  Run: 1 Event: 1

got data of type "RBCBoardSpecs" with name "" in record RBCBoardSpecsRcd


%MSG
CORAL/Services/ConnectionService     Info New session on connection to service "myrbconfig.db" started for user
"". Connection Id=2ce9888a-c9dd-11dd-8ebb-000423d657a6
CORAL/Services/ConnectionService     Info New session on connection to service "myrbconfig.db" started for user
"". Connection Id=2ccab5cc-c9dd-11dd-8ebb-000423d657a6

%MSG-s DataGetter:  EventSetupRecordDataGetter:get 14-Dec-2008 13:46:06 CET  Run: 1 Event: 1

got data of type "TTUBoardSpecs" with name "" in record TTUBoardSpecsRcd

%MSG

=============================================

MessageLogger Summary

A realistic example: using a Oracle test database

Using a more realistic case is not much different from the previous example. Basically, you will only to setup a couple of environment variables and make some changes in the configuration file. First, you need to know:

  • a developer area: at cms this is usually devdb10
  • an user: each subgroup has a generic user to access a area. this is given in the format CMS_RPC_COMMISSIONING
  • a password: ask for this one

Second, modify your configuration file of your Conditions Maker code. You will basically need to change the following lines:

process.CondDBCommon.connect = cms.string('oracle://devdb10/CMS_RPC_COMMISSIONING')
process.CondDBCommon.catalog = cms.string('file:test.xml')

also inside the definition:

process.PoolDBESSource = cms.ESSource("PoolDBESSource",
                                      ....
                                      connect = cms.string('oracle://devdb10/CMS_RPC_COMMISSIONING') 

The full configuration files (for both writing and testing) are here:

There are two environments variables for authentication: CORAL_AUTH_PASSWORD and CORAL_AUTH_USER with the information you have.

Observations:

  • At first the writing did not work and the reason was to the fact that the data was not being filled with values. You will need that your constructor or other method help in adding a set of default values as mentioned before.
  • Once you are able to write to the Oracle database, you cannot keep using the same Conditions Maker. Your tables are already uploaded and cannot be updated (only new data can be added). Therefore if you require to modify your objects (i.e.change the whole schema), you will need to clean up (remove tables and tags):

  • Warning, important Very important: this is a developer's area which means that it is not backed up. The following instructions (FAQ:How to clean up data from development database) solve your problem but the first thing to do is to check that you will not affect the work of other people. You can be safe if you proceed first with the following command:

cmscond_list_iov -c oracle://devdb10/cms_rpc_commissioning -u CMS_RPC_COMMISSIONING -p apassword -a

In this way you can see your own tags before proceeding with any deletion.

Summary

In this page I summarized the steps involved in adding two conditions objects. These objects are accessible to my application from the EventSetup which is passed as an argument to my analyzer method. The first step was to expose and register the conditions objects to the EventSetup. The next step was to make sure the EventSetup can see those objects and get the data out of the selected persistent mechanism.

To conclude, I wanted to compare the persistent object integration picture (Ref 1) in a Object Oriented Database Model and what we have done in this case and the elements involved. It is just made for illustration purposes.

  • Persistent objects integration model and how it could be associated to the process described in this page
    database-objects.jpg
  • Ref 1: Loomis M. and Chaudhri A. , Object Databases in Practice, Prentice Hall PTR, N.Y. 1998
Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatcc RPCTTConfMaker.cc r2 r1 manage 3.2 K 2008-12-18 - 09:14 AndresOsorio Configuration Maker - definition
Header fileh RPCTTConfMaker.h r2 r1 manage 1.5 K 2008-12-18 - 09:14 AndresOsorio Configuration Maker - declaration
JPEGjpg database-objects.jpg r4 r3 r2 r1 manage 114.6 K 2008-12-15 - 10:22 AndresOsorio Summary-Persistency diagram and cartoon of what we seem to have in cmssw
JPEGjpeg sqlitebrowser-myrbconfig.db-view.jpeg r2 r1 manage 168.7 K 2008-12-18 - 09:19 AndresOsorio sqlitebrowser snapshot
Texttxt test_oracle_cfg.py.txt r2 r1 manage 1.0 K 2008-12-18 - 09:15 AndresOsorio oracle - test for creating conditions objects
Texttxt test_oracle_get_cfg.py.txt r2 r1 manage 1.5 K 2008-12-18 - 09:15 AndresOsorio oracle - test for reading conditions objects through EventSetup
Texttxt test_sqlite_cfg.py.txt r2 r1 manage 1.0 K 2008-12-18 - 09:16 AndresOsorio configuration file for testing the RPCTTConfMaker: it creates a sqlite file
Texttxt test_sqlite_get_cfg.py.txt r2 r1 manage 1.5 K 2008-12-18 - 09:16 AndresOsorio configuration file for testing the RPCTTConfMaker: it reads a sqlite file and looks for the objects
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r11 - 2010-06-11 - PeterJones
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback