Hi,

 

Good news.  I basically just implemented a system for reading the conditions database records in a pretty generic fashion.

 

Everything is in org.lcsim.hps.conditions or its subpackages.  Dima’s classes are not used any longer and were moved to the demo sub-package.  The test case I wrote calling his sample code still works fine.

 

DatabaseConditionsReader is the generic implementation of the reader.  It will cache the meta data for each validity record (table, row, id), but does NOT call any converters automatically.  This must be done from user code.  (covered below)

 

The ConnectionParameters object encapsulates all the database information.  The default works with our test database at SLAC.  The reader is automatically setup with this.

 

DatabaseConditionsConverter is a generic type that actual data converters need to extend in order to create the application objects from the database rows. 

 

There is a “dummy” class SvtCalibrationConstants in the svt sub-package for modeling the SVT calibration data, along wth an associated converter to produce the objects of that type.  This is where you will come in and flesh out how the SvtCalibrationConstants are actually going to work, how others will access it, and what level of backward compatibility you will maintain.  (More or less, that is all up to you and the other coders of SVT stuff.)  You can even replace the sample class I wrote there with something better.  What I added is just an example.

 

There is a test at DatabaseConditionsReaderTest which shows how to use the system, and it passes fine.  This is actually similar to the code you would use for loading the conditions for reconstruction.  It just loads up the dummy record I put into svt_calibrations for testing.

 

The data_ident for SVT calibration looks like this:

 

svt_calibrations:set_id:1

 

That means it reads from the svt_calibrations table, uses set_id as the identifier for the data set, and looks for a value of 1 for the set_id.  Each different set of SVT calibration data should be given a unique set_id.  For now, this has to be done manually.

 

The data table for the conditions looks like this:

 

mysql> describe svt_calibrations;

+----------+---------+------+-----+---------+----------------+

| Field    | Type    | Null | Key | Default | Extra          |

+----------+---------+------+-----+---------+----------------+

| id       | int(11) | NO   | PRI | NULL    | auto_increment |

| set_id   | int(11) | NO   |     | NULL    |                |

| fpga     | int(11) | NO   |     | NULL    |                |

| hybrid   | int(11) | NO   |     | NULL    |                |

| channel  | int(11) | NO   |     | NULL    |                |

| noise    | double  | NO   |     | NULL    |                |

| pedestal | double  | NO   |     | NULL    |                |

+----------+---------+------+-----+---------+----------------+

 

The specific code for loading the sample calibrations, which is found in the test case, is as follows:

 

CachedConditions<SvtCalibrationConstants> c = manager.getCachedConditions(SvtCalibrationConstants.class, "svt_calibration");

SvtCalibrationConstants calibration = c.getCachedData();

 

The “svt_calibration” is the type of conditions, which is separate from the table name.  I used the calib_type field for this, though I am not sure this is the appropriate field.

 

Basically, you can see that the converter is obtained automatically by its mapping to the data class SvtCalibrationConstants. 

 

There’s a few more details to explain, but it would probably be best if you insert real calibration data into the table I made and then attempt to load it into lcsim.  Then you can ask me if any problems come up.

               

--Jeremy