Open amaltaro opened 8 years ago
@amaltaro "None for lumi " may caused by there were only run numbers in the data. If no lumi in the data, what is a good way to represent the data? Maybe null, not none? Any example runs?
For "the duplicate keys returned" , I did not see there were duplicated keys in the example. can you provide another one?
"None for lumi " may caused by there were only run numbers in the data. If no lumi in the data, what is a good way to represent the data? Maybe null, not none? Any example runs?
I would expect every EDM data registered in DBS to have at least: >= 1 run number, >= 1 lumi, and >= 0 events. Unless something was different back when we were using DBS2? This ticket was also created in 2016, so I definitely do not remember which data I was looking at back then (and the issue description is somehow poor!).
For "the duplicate keys returned" , I did not see there were duplicated keys in the example. can you provide another one?
Duplicate keys are in the WMCore DBS3Reader wrapper module (required for the DBS2 to DBS3 transition). So this one is on our side, Yuyi.
@amaltaro
CMS data inputting to DBS are improved a lot over the years. So the data w/o lumi might come from dbs2, but the dbs3 schema has limits on these, so we should not have a lot of data with no lumis.
While investigating other problems, I noticed there is some cleanup (and also improvements) needed for the DBS3 APIs in DBS3Reader.
One concrete example would be the misleading
listRunLumis
api that is supposed to return run and number of lumis, but it returns None for the lumis.A second example would be the duplicate keys returned and used all over the code, though this one is going to be really a challenge to get cleaned up, e.g.:
We should also review other APIs and try to get the best performance out of them.