Invalidate hub-wide caches on deletions and overwrites

[teh-cmc]

Hub-wide caches now subscribe to store events and invalidate accordingly in the face of deletions and overwrites.

This is a crutch to compensate for the lack of secondary caching, but a much needed crutch: the Rerun Viewer can now effectively be used as a soft realtime telemetry system.

24-09-26_18.23.02.patched.mp4

• Fixes static=True image logging still stores all the data #7404

---

Checklist

EncodedImage

for _ in range(0, 100):
    rr.log("image", rr.EncodedImage(path=image_file_path), static=True)
    time.sleep(0.01) # give time for the viewer to query and cache it

Before: 🟥
After: 🟢

Mesh3D

for _ in range(0, 100):
    rr.log(
        "triangle",
        rr.Mesh3D(
            vertex_positions=np.tile(np.array([[0.0, 0.0, 0.0], [1.0, 0.0, 0.0], [0.0, 1.0, 0.0]]), (33333, 1)),
            vertex_normals=[0.0, 0.0, 1.0],
            vertex_colors=[255, 0, 0],
        ),
        static=True,
    )
    time.sleep(0.01) # give time for the viewer to query and cache it

Before: 🟥
After: 🟢

Asset3D

for _ in range(0, 100):
    rr.log("world/asset", rr.Asset3D(path=sys.argv[1]), static=True)
    time.sleep(0.01) # give time for the viewer to query and cache it

Before: 🟥
After: 🟢

TensorData

for _ in range(0, 1000):
    rr.log("tensor", rr.Tensor(tensor, dim_names=("width", "height", "channel", "batch")), static=True)
    time.sleep(0.01) # give time for the viewer to query and cache it

Before: 🟥
After: 🟢

AssetVideo

frame_timestamps_ns = video_asset.read_frame_timestamps_ns()
rr.send_columns(
    "video",
    times=[rr.TimeNanosColumn("video_time", frame_timestamps_ns)],
    components=[rr.VideoFrameReference.indicator(), rr.components.VideoTimestamp.nanoseconds(frame_timestamps_ns)],
)

for _ in range(0, 100):
    rr.log("video", video_asset, static=True)
    time.sleep(0.01) # give time for the viewer to query and cache it

Before: 🟥
After: 🟢

---

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using examples from latest main build: rerun.io/viewer
  • Using full set of examples from nightly build: rerun.io/viewer
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!
• If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

• PR Build Summary
• Recent benchmark results
• Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

[Wumpf]

👍 nice

looking forward to making the caches more of a store aware thing so we can streamline some of the quasi-copy-pasted code here, but this will do for now; at least it's flexible enough (via being very stupid/simple) to deal with fallbacks & blueprint shenanigans.
(that's pretty much what you mean when complaining about the lack of secondary caches, right?)

[teh-cmc]

that's pretty much what you mean when complaining about the lack of secondary caches, right?

A real secondary cache would be aware of query semantics, and any shadowing introduced by these semantics, which is way more powerful and capable than working with row-ids directly.

E.g.:

• it would know to evict temporal data that is shadowed by newly logged static data.
• it would know to evict data that is using latest-at semantics if the same index was relogged to.
• it would know to evict data if its index is shadowed by a (possibly recursive) clear.
• etc.

None of those are possible when working with row-ids directly.

[Wumpf]

query awareness is the keyword I was missing for my mental model, makes sense, thanks. Given what visualizer queries look like right now it sound quite challenging.
I figure a good first/next step would be to have more unified mechanism to store all data sources of a given query-entry (i.e. a list of rowids potentially from several stores (rowids are unique so the several store bit doesn't technically matter)) 🤔. Unfortunately that's not really enough since fallbacks may be generated using heuristic output that may change every frame. In that sense we can't make these caches "pure" secondary caches.