-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QC-686 Allow apply Reductors to CCDB data in TrendingTasks and alike #2110
Conversation
This commit brings the possibility to apply Reductors to CCDB objects. To achieve that, the former Reductor (which assumes the expected type as TObject*) has become ReductorTObject, while ReductorConditionAny lets us retrieve any type which has a dictionary with retrieveConditionAny method. For better separation and easier testability, I extracted that method into a separate ConditionAccess class.
assuming the presence of the expected object in the database for given timestamps, the LHC phase can be trended with the following config: ``` "LHCClockPhaseTrend": { "active": "true", "className": "o2::quality_control::postprocessing::TrendingTask", "moduleName": "QualityControl", "detectorName": "TST", "dataSources": [ { "type": "condition", "path": "TOF/Calib", "names": [ "LHCphase" ], "reductorName": "o2::quality_control_modules::common::LHCClockPhaseReductor", "moduleName": "QcCommon" } ], "plots": [ { "name": "lhc_phase", "title": "LHC Phase trend", "varexp": "LHCphase.phase:time", "selection": "", "option": "*L", "graphAxisLabel": "Mean X:time" } ], "initTrigger": [ "userorcontrol" ], "updateTrigger": [ "10 seconds" ], "stopTrigger": [ "userorcontrol" ] } ```
a7d75f4
to
181f391
Compare
@ercolessi FYI, I could get a seemingly valid trend with the attached postprocessing-lhc-clock.json and the following execution command:
Also tagging @mlesch , who would be probably interested in seeing a real-world example of a ccdb object reductor (see |
@Barthelemy ready for review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, good, not sure I would have named them ReductorTObject
and ReductorConditionAny
but that's a detail !
Thanks,
Ugly, but working... I am still looking into ways of better separation between
ObjectGetter
andUserCodeInterface
and avoid renaming all the currently inheritedReductors
.Some cleanups still needed as well