I have a small problem with the policy "OnEachSeparately" for checks. QC is supposed to store created quality objects in checks/detectorName/checkName/taskName/. Which is the behaviour I observe, if I run QC with "host": "localhost:8080" in json file.
But if I run the same script with "host": "ccdb-test.cern.ch:8080", these quality objects are not stored. They are for sure created because the histograms are beautified correctly, but I can’t find the quality objects themselves:
(Here the TrackClusterCheck* are old checks.) So one can see, that even the folder was not created.
Do you know, why this is happening? Any help would be appreciated.
Dear Laura,
Unfortunately both @bvonhall and @pkonopka are absent but I believe if it’s matter of GUI I may be able to help.
Could you just clarify few points.
Do you use all the time the same, local GUI? Or you use “qcg-test.cern.ch”?
The difference between two setups is that in former you use local CCDB (QCDB) and in later ccdb-test.cern.ch?
I use json file with "host": "ccdb-test.cern.ch:8080". I run QC and look at the results in https://qcg-test.cern.ch. And this is where I can’t find the quality objects.
I use json file with "host": "localhost:8080". I run QC and look at the result in http://localhost:8081. And this where everything works as it should. (so local GUI)
Hello everyone,
I think I understand what is the problem. This is what I have done:
curl -i -F blob=my.root ccdb-test.cern.ch:8080/qc/TST/PiotrTest/histo/1/10000000
# checked on QCG if the objec is there - yes
# adding more objects under the previously uploaded object - the original object path becomes a directory!
curl -i -F blob=my.root ccdb-test.cern.ch:8080/qc/TST/PiotrTest/histo/histo1/1/10000000
curl -i -F blob=my.root ccdb-test.cern.ch:8080/qc/TST/PiotrTest/histo/histo1/1/10000000
# check again, the objects were successfully uploaded, but they are not visible in the tree structure in QCG
I think that QCG when seeing an object with path x/y/z does not show objects under paths like x/y/z/asdf. It is actually possible to use the QCG search engine to find them (I could find Laura’s objects that way).
It worked correctly on the local instance probably because there was no object called “qc/checks/TPC/TrackClusterCheck” there.
After a short investigation I found the following:
QCG will not create a folder for objects if there is an object already with the same path
So lets take as an example the following list of objects:
qc/TST/PiotrTest/histo/histo1
qc/TST/PiotrTest/histo/histo2
qc/TST/PiotrTest/histo
As you can see the object name from last element(histo) is the same as the name of the directory of objects (histo1 and histo2)
Because of this, QCG cannot differentiate between the 2 types(directory and object) and will only show the object.
That is why Piotr was able to see the objects when searching. In the search table there are no directories so the issue will not happen.
I would recommend for the moment to make sure the above will not happen when you publish the objects. I will be looking for a fix in the meantime.
To be more precise for @lserksny case. It works locally because you do not have those old object TrackClusterCheck and QCG will not have the problem of having the same directory and object name because there are none.
Just to add a little bit of QC context for Laura - the old object TrackClusterCheck probably appeared when you (or someone else) have used a different policy type, which generates an object with such path.
Deleting that old object should help. Let me know if you want me to do it - it can be done only by an HTTP request, AFAIK, so bad things may happen if you accidentally specify a too general path.
