Managing RCP Objects in Run II

Alan Jonckheere, Marc Paterno, Harrison B. Prosper D0RUG 24-June-1998

Basic Principle

For every object within an event, it should be possible to tell with which RCP objects is was constructed. This leads to the following goal.

Goal

Tag every event, unambiguously, with the RCP objects with which the event objects were constructed.

Solution

Store RCPIDs in events.

RCP objects are read-only objects that have unique identity determined by content. There is a one-to-one correspondence beween RCP objects and RCPIDs. Thus, an RCPID is a proxy for the unique RCP identity.

Implementation

The best, and simplest, way to maintain a growing set of unique RCP objects, over many years, is to use a real database.

And no, it does not have to be an object-oriented one! A relational database will do, since every RCP object is a tree, and every tree structure can be stored in such a database. We should avoid the DBL3, FATMAN, RZ etc. cottage industry that plagued us in Run I. We have ORACLE, a robust commercial relational database; so let's use it. Moreover, having stored RCP objects in a database we shall be able to query them using standard tools, like SQL.

Protocol for Managing RCP Objects

The diagram below illustrates how RCP objects are to be managed. RCP objects' ultimate repository is RCPDb, the relational database. However, this database can be accessed via two different paths:

Write-only access from CVS
Controled read/write access via the World Wide Web

All RCP files associated with the reconstruction program must go via CVS. The reconstruction program will reject any RCP object that has not entered the RCP database via this path.
The RCP database (RCPDb) will be automatically updated upon every code release from the CVS repository.
RCPDb will be automatically exported to a directory tree with the general structure

RCP/Package/

Package denotes the name of either a reconstruction package, an analysis package (e.g., SUSY, HIGGS, TOP etc.) or a Monte Carlo package.

RCPDb Update Algorithm

Find the set of RCP objects in a CVS release.
For each RCP object check
If RCP object in RCPDb Then
Tag with CVS release version
Else
Create new RCP object in RCPDb
Tag with CVS relese version

Thus, while there is a one-to-one map between RCP objects and RCPIDs, there will be, in general, a one-to-many map between RCP objects and CVS version numbers.

The User's View

Basic Principle

An RCP object should be identifiable using a unique triplet of the form (package, name [, release]). If the release version is omitted then the default version is that specified by the BFCURRENT environment variable. An important design goal is render access to RCPDb, or its proxy RCPDbExport, transparent to the user. The user should be unaware of the database.

Interface

Here are code fragments illustrating the minimal interface between the user and the RCP system.

RCPManager m;
// Create an RCP manager
// This will use the method getBFCURRENT() to obtain the CVS version number of the current code release.
RCPManager m(string releaseVersion);
// Create an RCP manager and override the default CVS version number with the version specified in the variable releaseVersion.
RCP r = m.extract(package, name [, release]);
// Return an RCP object, specified by the triplet (package, name[, release]).

Search Protocol for RCP objects

First look locally, then in a group area, then in RCPDb.

RCPIDs encode the provenance of RCP objects. RCPIDs discriminate.

Priority Tasks

Implement direct export from CVS to RCPDbExport, as an interim solution. Once RCPDb exists the export will be from RCPDb to RCPDbExport.
Implement the database access methods in the RCPManager. Initially, these would access RCPDbExport.
Incorporate the new RCP parser object, which understands vector types.
Implement vector types in RCP objects.