New DataBase reading metadata & process added

RESTFramework
1

We have added new processes and metadata for database reading and writing:

  • TRestDBEntryLogger(by nkx)

  • TRestMySQLToAnalysisProcess(by javier)

In future we shall write several classes implementing TRestDataBase adapting to each experiment’s database setup. The above metadata/processes shall be using TRestDataBase interface all the time, and avoid appearing concrete table/column name.

2

Could you give an example of use?

There are some changes required at TRestMySQLToAnalysisProcess?

3

Introduction of TRestDBEntryLogger:

This metadata can be put ahead of all others metadata sections in TRestRun section. During initialization, it will ask the user to fill a txt file which contains several lines of run/detector information.

<TRestRun>
  ...
  <TRestPSQLEntryLogger name="DBinfo" skipIfNotEmpty="false" EditWith="vim"/>
</TRestRun>

The txt file is like:

-- updating run in database, id: 6907, version: 2.2.17. Delete this line to cancel.
type: HW_DEBUG
tag:
description: hahaha test
mms_tag: Prototype_7MM
mms_idlist: {0,2,3,4,6,8,9}
mms_active: {f,f,f,t,f,f,f}
mms_hv_mesh: {0,0,0,-300,0,0,0}
mms_hv_internalrim: {0,0,0,0,0,0,0}
mms_hv_externalrim: {0,0,0,0,0,0,0}
mms_aget_boardid: {2,1,2,1,0,3,0}
mms_aget_chipid: {3,12,12,3,12,6,3}
mms_aget_dynamicrange: {0,0,0,120,120,120,120}
daq_threshold: 2-0
daq_samplingrate: 5
daq_triggerdelay: 150
daq_shappingtime:
gas_material:
gas_pressure:
gas_temperature:
gas_flowrate:
gas_driftvoltage: -10
gas_elifetime:
elog:

Here each line represents a column’s name and value in database of the current run. After closing the file, TRestDBEntryLogger will write the above information into the database by calling TRestDataBase::add_metadata().

TRestDBEntryLogger itself can be saved in output root file, keeping the above name-value pairs accessible as metadata

4

I am afraid there will be many changes required to make it general. The key point is, we need to move its database querying functionality inside independent class, just like TRestDataBasePSQL.

5

I understand that TRestPSQLEntryLogger might be handy and that I guess you will interface with PandaX-III daq so that user defines inputs and starts the acquisition system?

So if we need to make many changes to TRestMySQLToAnalysisProcess, forget it, we keep as it is. No need to make an extra effort to adapt the process. The process is working and functional. It will take too much effort, from many people, to adapt things I dont know what reason. We cannot keep working on interfacing things. We need to work on results.

I think it is not good to create too many interconnections. To have simple working processes with a basic function, performing a particular task, is what we need. No need to increase the complexity.

It is better to keep TRestMySQLToAnalysisProcess independent.

6

So, it is optional? Writing it should not be the default option?