Make Visible History explicit about the choice between "latest at" and "range" queries

[abey79]

Given time bounds A and B, our current querying model consist of "everything logged between A and B, if empty then whatever logged just before A", aka "latest at" and "range" semantics are fused. A "latest at" query are currently used when "A = B" instead of "range" query (actually only if "A = B = current time" IIRC), but that can be seen as an optimisation, as a "range" query with the same bounds would lead to the same result.

We must clarify the querying model and separate these semantics from each other. The query should either be "latest at A" or "range between A and B", the latter without leaking latest at semantics.

This involves changes in multiple areas:

• the query code should support range queries without latest at semantic: Add support to skip the "latest_at" semantics with range queries #4192
• the visible history entity property should become an { latest_at, range } enum
• the visible history UI should be updated accordingly

This change can be seen as a starting point towards an even richer query ecosystem, e.g.:

• Strided visible history #1648
• Add support for "onion skin" rendering of visible history #4106

[teh-cmc]

Given time bounds A and B, our current querying model consist of "everything logged between A and B, if empty then whatever logged just before A"

Either I'm misreading this or that's incorrect: range queries over a range A->B always return a snapshot of the compacted state at A-minus-1 and then iterate between A and B, irrelevant of how much data there is between A and B.

A "latest at" query are currently used when "A = B" instead of "range" query (actually only if "A = B = current time" IIRC), but that can be seen as an optimisation, as a "range" query with the same bounds would lead to the same result.

LatestAt(frame=42) and RangeAt(frames=42..=42) are not equivalent: range queries expose sub-timestamp events and walk forwards in time while latest-at queries work at a timestamp level and do so by walking backwards.

E.g.

rr.set_time_sequence("frame", 42)
rr.log("mylogs", rr.Text("hello"))
rr.log("mylogs", rr.Text("world"))

LatestAt(frame=42): [
  `mylogs` @ frame=#42: [Text("world")]
]

RangeAt(frames=42..=42): [
  `mylogs` @ frame=#42: [Text("hello")]
  `mylogs` @ frame=#42: [Text("world")]
]

We must clarify the querying model and separate these semantics from each other. The query should either be "latest at A" or "range between A and B", the latter without leaking latest at semantics.

I very much want to clarify all of this and actually meant to open an issue about this, but not by separating them... on the contrary, by merging all query kinds into just one single configurable query type. 😅

[abey79]

Thanks for the clarifications, it would actually be shocking if I had the details right :)

on the contrary, by merging all query kinds into just one single configurable query type.

This is fine. What's important is that:

1. the blueprint property data structure models the various kinds of queries (or, in your parlance, the various kinds of query configurations) that we want to offer to the user, and
2. the UI "just" reflects the content/organisation of that structure

No constraints on the query-ies API, so long as it works to implement the behaviour modelled by (1).

Worth remembering that our language around queries (latest at vs. range vs. strides, etc.) might/should be slightly different in a user-facing context (i.e. blueprint props data structure and UI, where we might have various "types of queries") vs. in a data-store context (single "configurable" query into the store).

[abey79]

Example of phenomenon inherent to our current query model:

range_vs_latest_at_queries.mp4

[teh-cmc]

Range queries don't have this weird behavior anymore (they are now multi-tenant proof).