Concept of an extended version management in Oracle for condition-like parameters in the analysis
by Ilse Koenig, GSI Jan 25, 2002
Introduction
Many data needed in the analysis change over time: lookup tables, calibration parameters, conditions, ... All these data need a version management.
The data are stored in the analysis in parameter containers and many of them rarely change their structure. Each parameter container belongs in Oracle to a set of dedicated tables and the parameters itself are typically stored as columns in these tables. There is only one valid version for these parameter sets for each run (see also Actual version management in Oracle).
Parameter containers for conditions need to be stored differently because of the following requirements:
- There might be simultaneously different valid versions for the conditions depending on the context (purpose) in the analysis.
e.g."RichAnaMinimumBias", "RichAnaNormalBias", ... for the RICH analysis parameter container.
- The code is often not stable and with each code version, the persistent data member in the class changes.
This second point is the most critical:
Not all people use the actual code and parameters for older beamtimes have been stored in Oracle with an older code version. Storing the parameters the old fashioned way (one valid for a parameter set and storage of the parameters as table columns) would lead to the fact, that one has to add columns with each change of the code and to store old parameter sets as a new version. Additionally the interface to Oracle has to be changed. Then it is not possible anymore to read the parameters from Oracle with an older code version.
To overcome these problems, I propose to store conditions in a more generic way.
Concept for conditions
The basic idea is the following:
- Conditions are stored as strings of
- parameter name
- parameter value
- parameter type
- Each parameter gets a version management in Oracle for itself, not for the parameter container. The parameter knows to with parameter container it belongs. Each value of the parameter belongs to a certain context and is valid for a certain time period. It can be changed, but the history is kept, to know all the time also the values retrieved in the past.
- During initialization, the analysis interface to Oracle reads the start time of a run and reads the list of parameters belonging to the parameter container (class), which have a valid time period, into which the run start falls.
Depending on the storage, this list might contain more parameters as needed by the actual code version. The parameter container takes from the list only the parameters needed and stores the values in the actual data members. An appropriate error management is needed to guarantee that all parameters are initialized.
- A parameter container can be written to a "Load" table in Oracle, not to the final table. The only purpose is, to get the data to the server. Many different versions can be written, but they are not yet retrievable for initialization. The validation of certain versions is possible via a Web interface (WebDb applications).
- Any manipulation of the data in the final tables can be done only via a web interface.
As a first version I have written a simple interface class (code .../base/runtimedb/hparamlist.h, *.cc), which has as a data-member a TList and member-functions to add and find parameters in the list. The member-functions are overloaded for all basic types (int, float, double, long, string) and for TArrays of type int, float and double. Conversion from and to strings is done via these functions.
The base class HParSet was changed to support a context, A new class HParCond, derived from HParSet, was introduced, which provides the virtual functions for filling the parameters into/from a list.
The Oracle interface is implemented in the base class HDetParOraIo (read and write).
Thus, a minimum of code is required to use this application.
Implementation in Oracle (access via WebDb)
The analysis writes the data to LOAD-tables in Oracle. A web based GUI (via WebDb) has been developped to move the data from these LOAD-tables to the FINAL-tables and to specify the validity time ranges. Any manipulation of the data can be done (only) via forms.
The GUI provides also public accessible (user HADES) applications, to query the parameters.
Access to the GUI:
enter WebDb: http://webdb.gsi.de:8010/pls/hades_webdbs (with hades hades in login window)
or from the Analysis Logbook: Click on WebDb Site
Click on HYDRA Parameters on the left navigation bar and then on Params & Conds.
Testing and playing with the GUI should NOT be done on the production account HANAL.An almost identical GUI for testing and playing is available via
Side Map -> IKOENIG -> Test Version of the GUI for Analysis Conditions