Container names in new database
In the old implementation of the configuration database the configuration containers were named after the persistent classes of the objects populating these containers. For example we had containers OrcConfigP:Default, L3DT2DP:Default, etc. This had few unpleasant consequences:
- it does not support polymorphism, as the result we saw clumsy names like L3DT2DP_001:Default,
- these names are specific to a particular implementation and do not make any sense for the implementations with the different persistent class names.
When designing new configuration database it was decided that the containers will be renamed to better reflect essential features of the configuration database.
Because in the new database the only client-accessible classes are transient classes, it was decided to use the transient class names for the container names. Here is the table with the correspondence between old class names and new container names:
| Old name | New name |
| BdbConfigAliasMap | CfgRuntypeList |
| BdbConfigFileIdentifier | RdfFileIdentifier |
| BdbConfigFileP | CfgFileData |
| BdbConfigMap | CfgMap |
| BdbConfigSampleObject | CfgSampleObject |
| BdbConfigTopMap | CfgTopMap |
| CalConfigTypeP | CalConfigType |
| DchdTagGeomP | DchdTagGeom |
| DchFeeStateObject | DchFeeStateDual |
| DchMapBrowserP | DchMapBrowser |
| DchOnlineConfigP | DchOnlineConfig |
| L1DBltMaskP | L1DBltMask |
| L1DBltZpdSimpleConfigP | L1DBltZpdSimpleConfig |
| L1DTsfConfigP | L1DTsfConfig |
| L1DTsfLutArrayP | L1DTsf5BitLutArray |
| L1DTsfLutArrayP_001 | L1DTsf6BitLutArray |
| L1DZpdBasicLutP | L1DZpdBasicLut |
| L1DZpdDecisionModLutP | L1DZpdDecisionModLut |
| L1EmtAxRawDataP | L1EmtAxRecord |
| L1EmtFcxRawDataP | L1EmtFcxRecord |
| L1EmtFxRawDataP | L1EmtFxRecord |
| L1GltConfigP_001 | L1GltConfig |
| L3DConfigP | L3DConfig |
| L3DGeomP | L3DGeom |
| L3DT2DP | L3DT2D_ex |
| L3DT2DP_001 | L3DT2D |
| L3DTrkList | L3DTrkList |
| L3EChannelMaskP | L3EChannelMask |
| OdcBdbConfigFile | OdcConfigFile |
| OrcConfigP | OrcConfig |
| OrcCPMaskP | OrcCPMask |
| SvtChipsConfigP | SvtChipsConfig |
| SvtRunConfigP | SvtRunConfig |
The "secondary keys" of the containers are not affected by this change and remain the same, so that if the full container name in the old database was DchOnlineConfigP:setupFEE, in the new database it will be DchOnlineConfig:setupFEE.
To list the names of the containers in the new database one can use CfgUtils command, for details see the CfgUtils documentation accessible from online databases web page. For quick reference here are few common container names in the new system:
- CfgTopMap
- Container for the top maps (or top keys.) It exists only in the 'top' database.
- CfgRuntypeList:Default
- Container for the runtypes (alias maps in the oldspeak.) Almost every subsystem has this container, objects in this container define the runtypes for that subsystem.
- CfgMap:Sys
- Container for the system-level maps, e.g. CfgMap:Dch. Every subsystem has this container, and top maps reference objects in this container only.
As it was mentioned above, new system has full support for polymorphism, which means that there are no restrictions on which kind of object is stored in which container. Container is not necessary need to have the name of the class stored in it, instead it could be named after the "purpose" of this container. There are important exceptions though - containers CfgMap[:Anything] can only keep configuration maps, container CfgTopMap can only keep top map objects, and CfgRuntypeList:Default container can only keep runtype objects.
|
