QC post-processing task that updates on multiple monitoring objects

Dear QC experts,

I am currently developing a post-processing task that takes two MOs as data sources, like this:

        "updateTrigger": [
          "newobject:qcdb:MCH/MO/MCHDigits/Occupancy_Elec", "newobject:qcdb:MCH/MO/MCHDigits/DigitOrbitInTF"

Hence, the update() method gets called whenever either of the objects is updated in the QCDB. It is therefore called twice for each cycle of the MCHDigits task, once for each of the objects.

(The reason why I have a post-processing task with two input MOs is that I want all the corresponding post-processing plots to end up in the same QCDB folder.)

In my code I need to detect which object actually triggered the call to the update() method, to avoid processing the same MO twice. For this I am using the meta-data information associated to the MO, like this:

void PostProcessingDigits::update(Trigger t, framework::ServiceRegistry& services)
  auto& qcdb = services.get<repository::DatabaseInterface>();

  auto mo = qcdb.retrieveMO(mElecHistoPath, mElecHistoName, t.timestamp, t.activity);
  if (!mo) {

  std::string timeStamp{ "0" };
  auto iter =  mo->getMetadataMap().find("Created");
  if (iter != mo->getMetadataMap().end()) {
    timeStamp = iter->second;

  if (timeStamp != mElecHistoTimeStamp) {
  } else {
    std::cout << "MO \"" << mElecHistoPath << "/" << mElecHistoName << "\": time stamp not updated (" << timeStamp << ", was " << mElecHistoTimeStamp << ")" << std::endl;
  mElecHistoTimeStamp = timeStamp;

This seems to work correctly, however I would like to double-check that this is also reliable in the long term, or if there is a better way to check which MO triggered the call to the update() method.

Thanks a lot in advance!

Indeed at the moment there is no cleaner way to do that.

I suppose it would help if the trigger config string would be provided with the Trigger struct, then you should be able to check which of the two it was. Since it should be quite quick and trivial, I will try to find some time this week to implement this. Here is the ticket: Cern Authentication