Structure of Configuration database ROOT files

Introduction

Below is a technical description of the data structures stored by the configuration database in the ROOT files. Design of the storage was loosely based on the relational model, but because ROOT lacks some basic features of the relational databases it needed some additional structures to support efficient indexing. Analog of relations (tables) in ROOT is TTrees, and all the information in the ROOT implementation of the configuration database is stored in the ROOT TTrees. Below is description of the individual TTrees and their roles.

The tables (TTrees) are divided into the global tables and subsystem-specific tables. Subsystem-specific tables keep information specific to a specific configuration database (subsystem), and global tables keep shared information used by all subsystems. Global tables are stored in the root directory of the ROOT file, subsystem-specific tables live in the subdirectories named after the subsystems (properly capitalized like Dch, L3D, Top, etc.)

Global tables

Type table

This table defines the mapping between the type codes and type names. Type code is a plain number, type name is a ROOT class name. Table is a collection of the objects of CfgRootTypeTableEntry class.

Table structure:

• Table: __TypeTable__
• Branch: TypeInfo
• Leaf: _typeCode, type: ULong_t
• Leaf: _typeName, type: string

Shortcuts table

Shortcuts table stores the "quick path" information from the top map to the leaf nodes to avoid unnecessary navigation through the intermediate maps. This table actually consists of the TTrees, one with the actual data, another with the index information.

Table structure:

• Table: __Shortcuts__
• Branch: Shortcuts (stores CfgRootShortcutsEntry class)
• Leaf: _path, type: string, path to object from top map
• Leaf: _db, type: string, database name
• Leaf: _cont, type: string, container name
• Leaf: _key, type: ULong_t, configuration key
• Table: __ShortcutIndex__
• Branch: ShortcutIndex (stores CfgRootShortcutsIndex class)
• Leaf: _topKey, type: ULong_t, top configuration key
• Leaf: _firstIndex, type: ULong_t, first index in the shortcuts table
• Leaf: _lastIndex, type: ULong_t, last index in the shortcuts table

Subsystem tables

Every subsystem has its corresponding directory inside the ROOT file (like Dch, Orc, Top, etc.) Inside that directory there are two subdirectories with the names "containers", and "data".

Metadata tables

Containers subdirectory keeps the number of TTrees (tables), one TTree per container defined in that subsystem. The names of the TTrees correspond to the name of the containers, so for example inside the Dch/containers directory one can find TTrees "CalConfigType", "CfgMap:Dch", "RdfFileIdentifier:DchCalCycles", etc. Each container TTree has the same structure:

• Table: ContainerName
• Branch: ObjectPointer (stores CfgRootContObjPtr class)
• Leaf: _configKey, type: ULong_t, configuration key
• Leaf: _typeCode, type: ULong_t, type code from TypeTable
• Leaf: _objectTableIndex, type: ULong_t, index into the object table
• Branch: ObjectInfo (stores CfgRootContObjInfo class)
• Leaf: _created, type: ULong_t, time when the object was created
• Leaf: _user, type: string, user@host of the originator
• Leaf: _descr, type: string, description given to object

Data tables

Data subdirectory in the subsystem directory keeps the TTrees where actual data of the configuration objects are stored. These TTrees are named after the names of the ROOT persistent classes. For example, the directory Dch/data contains TTrees with the names "CalConfigTypeR", "DchOnlineConfigR", "CfgRootMap", etc. These TTrees store the objects of the same type, and they store the objects as "BLOBs" meaning that no splitting of the objects into branches happen at all. Thus there is no real structure inside these tables:

• Table: TypeName
• Leaf: data, type: any, configuration object serialized data

Picture

Here is the diagram showing few main components and their relation to each other:

Note that there is a link between the tables which does not fit in the true relational model. One could argue that this is a problem with this implementation, but it could also be a shortcoming of the relational model :)