AdHocTables

Introduction

The primary conditions database functionality is to store and deliver detector calibrations which are relevant for certain intervals of validity. Sometimes there is a need to store additional information that doesn't fit into this format. For example, saving a record of when and how certain calibrations were taken, what entries are historically related to each other, or other notes and history. ad hoc tables were implemented to meet this need.

We expect the content will be related to maintaining conditions data, and not truly arbitrary, since it is stored in the conditions database.

Implementation

The tables are defined using the same code as a calibration table, with the addition of this one method:

tableType type() const override { return Adhoc; }

this causes the code to not create metadata such as a CID, or intervals of validity, for commits. Similar to calibration tables, the ad hoc tables belong to a subdetector schema ("trk", "cal") and follow those naming schemes. They are not declared with "dbTool commit-table" and do not have a TID

To commit content to the table, prepare the new rows as csv, labeled with the table name, the same as a calibration table:

TABLE TstAdhoc1
# int, float, and string
0,  1.3, first comment
21, 2.3, another comment

and commit it

dbTool commit-adhoc --file TstAdhoc1_content.txt

and read back the table:

dbTool print-adhoc --name TstAdhoc1