Product aggregation logic does not correctly act on full-run range products
In the analysis of issue #18943, there was indication that aggregation is attempted on run products covering the full run.
This logic might be not ideal, and some discussion might be needed to determine the preferred behaviour.
Kyle Knoepfel can expand on the topic, as he was the principal investigator of the issue.
#3 Updated by Kyle Knoepfel about 3 years ago
- Category set to Metadata
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
- SSI Package art added
The fix has been implemented with commits:
Along with these changes came a few breaking changes.
File-format version change¶
There is a file-format version change (11 to 12) because full-run products persisted to disk now have a different representation than in past file-format versions. This allows us to disambiguate between products that represent a full run and those that correspond to no events. The consequence to the user is that all full-run products persisted to files with file-format version 11 and older will be interpreted as corresponding to no events. This means:
aggregatefunction for reading each already-persisted full-run product is required.
- The range-of-validity for one of these products will correspond to no events. This can make the interpretation of the product (for the user) ambiguous. However, assuming the user implements a sensible aggregation function for a full-run product (e.g. checking for equality and throwing if the values are different), this should not be an impediment for using these products.
Semantics of art::overlapping_ranges¶
In the past, the
bool art::overlapping_ranges(RangeSet const& a, RangeSet const& b) free function returned
b corresponded to the same ranges. With the next minor release of art, calling
overlapping_ranges will return
art::same_ranges(a, b) also returns