BaBar Configuration Database
Andy Salnikov, George Zioulas, Yury Kolomensky
The Configurations database is a component of the BaBar Online databases. There are configuration databases for each of the on-line subsystems. The term "Configuration database" refers to the whole set of these subsystem databases. (The term database is quite overloaded here, each subsystem database comprises one or mode Objectivity databases/files.)
The configurations data are encapsulated in the configurations objects. Every stored configuration object has an identity. The object identity is a quadruplet of the following entities:
- database name (subsystem name, lower-case TLA, e.g. dch, svt, trg, etc.),
- class name of the object (e.g. "BdbConfigFileId"),
- secondary key, which is arbitrary string, used to distinguish different configuration objects of the same class (it can be empty),
- famous configuration key, which is a 32-bit integer number.
Objects with the same class name and secondary key are stored in one container. Every time a new object is created in the container it is assigned the configuration key. Configuration keys of the objects in the same container are different. Configuration objects are never deleted or modified, this guarantees that it will be possible to reconstruct whole configuration for any given time in the past.
The identity of the object can be represented in the mix of the UNIX path-name and index notations, e.g.
orc/OrcConfigP:Default[3]
refers to the configuration object of the class OrcConfigP with the secondary key "Default" and configuration key 3 in the Orc database.
Configuration maps are used to organize the configuration objects in the tree-like structures (actually graphs, or event more precisely DAGs). Each subsystem has a set of maps which are stored in the subsystems configurations database. Maps are also configurations objects; they are assigned a ConfigKey and are stored in map containers. For example, the top-level map for SVT has a name (which is a secondary key) "Svt" and it is stored in a container with the same name; it refers to other maps, say "ChipsConfig", "RunConfig" etc. also stored in different containers with respective names. The maps have the named links to other objects, following this links one can navigate from some top-level map down to the basic objects. For example, already mentioned Svt map can have a link named "ChipsConfig" pointing to the map with the same name (although map name can be different), and "ChipsConfig" map can have links "Data" and "FileID" pointing to basic objects. Extending our notation this can be written as:
svt/BdbConfigMap:Svt[178] -> ChipsConfig = svt/BdbConfigMap:ChipsConfig[103]
svt/BdbConfigMap:ChipsConfig[103] -> Data = svt/SvtChipsConfigP:Default[107]
svt/BdbConfigMap:ChipsConfig[103] -> FileID = svt/BdbConfigFileIdentifier:SvtChips[104]
There is a special subsystem database with the name "top" which contains top-level maps referring to the subsystem maps. The top-level maps are the roots of the configuration trees. They have the links named after each subsystem pointing to the subsystem configuration maps, e.g.:
top/BdbConfigTopMap[1244] -> Svt = svt/BdbConfigMap:Svt[178]
top/BdbConfigTopMap[1244] -> Emc = emc/BdbConfigMap:Emc[111]
(the top-level maps have special class with the name BdbConfigTopMap and have no secondary key.)
Given the structure above and the top-level map with the key 1244 one can refer to the basic objects with the simple UNIX-path-like notation, e.g. "/Svt/ChipsConfig/Data" will refer to the object svt/SvtChipsConfigP:Default[107].
The alias maps are the configuration maps which are used to give some meaningful names to the top-level maps. Alias maps basically define the types of the runs, and they are living in the subsystem databases, e.g. alias maps in orc/BdbConfigAliasMap:Default define the data-taking types of runs and can have links "PHYSICS", "COSMIC", etc. to the top alias maps. Similar maps in dch database can define calibration types for Dch.
Creating and manipulating configuration trees using only numeric keys is quite tedious and error-prone task. To make life easier the alias trees were invented (the term can be confusing, but it seems impossible to rename things now). The alias trees serve as a template for building numeric trees. They define some meaningful names for the configuration keys, e.g. one can say that numeric key 45 in some container is called "PHYSICS" and 48 is "COSMIC". The alias trees repeat the structure of the numeric trees, but without involving numbers, so that above examples could be rewritten like this:
svt/BdbConfigMap:ChipsConfig[PHYS] -> Data = svt/SvtChipsConfigP:Default[PHYS]
svt/BdbConfigMap:ChipsConfig[PHYS] -> FileID = svt/BdbConfigFileIdentifier:SvtChips[PHYS]
svt/BdbConfigMap:Svt[SVT_PHYS] -> ChipsConfig = svt/BdbConfigMap:ChipsConfig[PHYS]
top/BdbConfigTopMap[TOP_PHYS] -> Svt = svt/BdbConfigMap:Svt[SVT_PHYS]
top/BdbConfigTopMap[TOP_PHYS] -> Emc = emc/BdbConfigMap:Emc[EMC_PHYS]
(all the aliases were chosen arbitrary). The numeric keys should still appear at some level for the basic objects:
svt/SvtChipsConfigP:Default[PHYS] = 107
svt/BdbConfigFileIdentifier:SvtChips[PHYS] = 104
but the intermediate maps are build with the names only. There are (or will be) tools to manipulate the alias trees using these notations (in simplified form) and make a "snapshots" of the alias trees which become ordinary numeric trees and alias maps.
All directory/file names and database/container names are generated automatically by the configurations database program. The naming conventions are described here. NOTE: the placement of the objects, containers and databases is not a fixed part of the design and can be changed any time without affecting API.
The subsystem databases are created in a directory named tla (lower-case TLA) after the Three letter acronym of the subsystem. The first database name is derived from tla like "cfg_tla_tla000000". The next database name is obtained by incrementing
the digits in the previous name. For example, the Drc databases are named cfg_drc_drc000000.bdb, cfg_drc_drc000001.bdb etc.
Objects and maps are stored in "smart" containers. Smart containers are special containers with the property that when a container overflows another one is created automatically and if there is not enough space in its database a new database is also
created. Containers are named after their class name "className" and a secondary key "secondaryKey" in the format "className:secondaryKey" or just "className" when secondary key is empty. Maps are stored in containers named "BdbConfigMap:mapName" where "mapName" is the name of the map (its secondary key).
Alias trees are stored in the ordinary containers named "#ALIASES#", there is one container per subsystem database. There are also lists of history records for each alias object which are stored in the smart containers named "BdbConfigATHistoryRecord:__AliasHistory__".
[For informative purposes only.]
$OO_DB_PATH/
|
+- configurations/
|
+- top/
| |
| +- top001000-001100/
| | |
| | +- cfg_top_top000000.bdb
| | |
| | +- cfg_top_top000001.bdb
| |
| +- top002000-002100/
| |
| +- cfg_top_top000002.bdb
| |
| +- cfg_top_top000003.bdb
|
+- xxx/
| |
| +- xxx001000-001100/
| | |
| | +- cfg_xxx_xxx000000.bdb
| | |
| | +- cfg_xxx_xxx000001.bdb
| |
| +- xxx003000-003100/
| |
| +- cfg_xxx_xxx000002.bdb
|
+- [.....]
|
