1. Andrea Valassi Pere Mato
Conditions Database
Andrea Valassi
Pere Mato

2. Overview of components
Framework design issues:
The Algorithms need not talk directly to the CondDB.
Within the Gaudi framework, CondDBSvc is the service responsible for updating the Transient Detector Store with data from the CondDB.
Software responsibilities:
LHCb-related issues are: CondDBSvc design and interface to CondDB; data format specification.
CondDB is being developed by CERN IT division
implemented in Objectivity
Framework Services
DetData Svc
CondDB Svc
DetPers Svc
Algorithms
Det Elem
Calib
Slow
Conditions
database
Align
Transient detector store

3. Overview of functionalities
Data blocks
real condition data (alignment...) + metadata (validity time, version, ...)
classified in «folders» according to SD and type: e.g. /Ecal/Module1/Calib
each folder contains the several data block versions for a given validity time
Tagging
global tags (à la CVS) identify a consistent set (1 block per validity time)
e.g. «ProductionCondDB», «MyTestCondDB»
Browsing of data in each folder
horizontally: along the validity time axis, according to a given global tag
vertically: along the version axis, for a given validity time
Database management
physical partitioning foreseen for different data taking years (and SD ’s?)
management of database files and write/read transactions

4. Data identification and versioning

5. Open issues in the design
HOW to store/retrieve condition data:
framework design of CondDBSvc (independent of data type)
synchronisation of Transient Detector Store used by the Algorithms
detector data identification
truly LHCb-specific: separation of Align/Slow/Calib or Vdet/Ecal/Hcal/Rich...
general to CondDB-design: versioning over multiple validity time ranges
interface and needed functionalities/features for the CondDB
general to CondDB-design, involves feedback to IT
WHAT to store as condition data:
may be different for Alignment, Calibration, SlowControl...
may vary from SubDetector to SubDetector
uniform implementation: store condition data as XML strings?

6. Interface to IT’s CondDB
Good collaboration and feedback with IT DB group
Stefano Paoli, Dirk Duellmann
in discussion with other experiments (Atlas, Compass...)
Parallel requirement documents:
from LHCb (Pere, february 2000)
from IT (Stefano, june 2000)
Open discussion on functionalities and interface
versioning schemas over multiple time validity ranges
global tag assignment
database browsing
database management
support of multiple storable data types
simple (XML strings) and complex (class instances, e.g. as Objectivity ooRef)

7. Plans and timescales Plans for CondDB from IT Work plan for CondDBSvc
current effort on collecting our requirements
first reasonable prototype could be ready in a couple of months from now
Work plan for CondDBSvc
use cases and requirements from SubDetectors
concentrate at first on one data type: Alignment
identify example SD(s) with condition data to store and algorithms to use it: Velo?
design and integrate software in the framework, test on the example(s)
iterate feedback to IT
My personal plans...
no time to work on it effectively before mid-August
getting started with Gaudi at first (DetDataSvc, DetPersSvc, XML...)
Summing up: prototyping of CondDBSvc around  October to December