BigScreen - Fixed retrieval of latest available QO#2081
BigScreen - Fixed retrieval of latest available QO#2081Barthelemy merged 1 commit intoAliceO2Group:masterfrom
Conversation
aferrero2707
force-pushed
the
big-screen-fixes
branch
from
c2d59c3 to
2712330
Compare
aferrero2707
changed the title
| const auto filterMetadata = activity_helpers::asDatabaseMetadata(activity, false); | ||
| const auto objectValidity = qcdb.getLatestObjectValidity(objFullPath, filterMetadata); | ||
| if (objectValidity.isValid()) { | ||
| timestamp = objectValidity.getMax() - 1; |
There was a problem hiding this comment.
why objectValidity.getMax() - 1 in particular?
There was a problem hiding this comment.
Thanks. There, max-1 is used because it is the max timestamp that one can use to access the object. In the case of the trigger, I use it because it makes the most sense as a timestamp of data points on trending plots.
In your case, I am wondering if using "Created-At" instead of "Valid-Until" - 1 could make more sense. If we use the first, you will consider an object as too old if it was not updated recently. If you use the latter, a regularly updated object, but with no new data since some time (max validity does not move) will not be considered as too old will be considered as too old as well. Personally, I am OK with both alternatives, so I think it's up to you.
There was a problem hiding this comment.
For the purpose of the BigScreen, I think it is useful to also identify the cases where an object is regularly updated but no new data is actually received, and show it as grey if the last new data is too far in the past. What do you think?
There was a problem hiding this comment.
Yes, indeed, this is something that shifters should be aware of.
So the algorithm would be:
- get the latest object validity
- if
now - created > x, consider the object as invalid, use an appropriate colour in the display - if
now - validity_end > yconsider the object as invalid, use an appropriate (different) colour in the display.
I would keep x and y as different parameters in case we want to tune them separately. After all, there is always some latency between the validity end and the object publication time.
Colour could be also different between the two, so it is clear which of the two cases we encounter.
There was a problem hiding this comment.
That's a very good suggestion! We can extend the logic in a separate PR, for example:
- grey color if
now - created > x(the processing is not creating new QOs) - yellow color if
now - validity_end > y(processing creates new QOs, but from the same old data)
3 participants
This PR fixes the retrieval of QOs when using periodic triggers. It introduces the ability to retrieve the latest available QO from the QCDB, instead of using the trigger's time stamp. The QO validity range is then compared to the time stamp of the trigger to check if the QO is recent enough to be displayed.