cmssw
cmssw copied to clipboard
Request "strict" flag in `EventSetup::getData()`
When using a snapshot GlobalTag
, when requesting a payload for a run that's beyond the end of the snapshot EventSetup::getData()
returns the value contained in the last IOV.
Sometimes it is useful to be sure that this is not the case (e.g. that a wrong GT is not used).
Possible solutions include adding a "strict" flag to the getData()
signature, or using another function called e.g. getDataSafe()
.
If the requested data is not in the IOV range of the GT, an exception could be thrown or some sort of error state could be set (leaving the responsibility to check it to the caller).
Example of unintended behavior: https://github.com/cms-sw/cmssw/issues/38812
A new Issue was created by @amecca .
@Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar, @qliphy can you please review it and eventually sign/assign? Thanks.
cms-bot commands are listed here
assign core, db
New categories assigned: core,db
@Dr15Jones,@smuzaffar,@ggovi,@makortel,@francescobrivio,@malbouis,@saumyaphor4252,@tvami you have been requested to review this Pull request/Issue and eventually sign? Thanks
Could this be a job-wide setting in CondDBESSource
/PoolDBESSource
?
@francescobrivio @makortel can you clarify if there is any showstopper here? I think there are application that could benefit from the required feature.
The Framework is specifically designed to behave like that (i.e. throw an exception if a given data is not in a given IOV range). It is the PoolDBESSource that would have to be changed. Unfortunately, the DB design does not have the concept of an 'end' for a range of IOV. The DB just has a since
designation and assumes the next since
is where the present IOV ends. If there is no next since
the PoolDBESSource just assumes the IOV continues for ever.
Thanks Chris for the explanation!
What about working with the GT snapshot instead of the IOV itself? As suggested in the issue description we could print a warning message in case the GT snapshot is smaller (earlier) than the latest IOV of the record? I guess it would work fine also for the online GT case which (by policy) have an "infinite snapshot".
Could the fwk/PoolDBESSource handle this?