DataStore changelog 3: introduce StoreViews

[teh-cmc]

Introducing the StoreView trait and registration system, allowing anybody to subscribe to DataStore changes, even from external code.

StoreViews global scope: by registering a view you subscribe to changes to all DataStores, including those that are yet to be created.
This is very powerful as it allows views & triggers implementers to build cross-recording indices as well as be notified as soon as new recordings come in and go out.

/// A [`StoreView`] subscribes to atomic changes in one or more [`DataStore`]s through [`StoreEvent`]s.
///
/// [`StoreView`]s can be used to build both secondary indices and trigger systems.
pub trait StoreView: std::any::Any + Send + Sync {
    /// Arbitrary name for the view.
    ///
    /// Does not need to be unique.
    fn name(&self) -> String;

    /// Workaround for downcasting support, simply return `self`:
    /// ```ignore
    /// fn as_any(&self) -> &dyn std::any::Any {
    ///     self
    /// }
    /// ```
    fn as_any(&self) -> &dyn std::any::Any;

    /// Workaround for downcasting support, simply return `self`:
    /// ```ignore
    /// fn as_any_mut(&mut self) -> &mut dyn std::any::Any {
    ///     self
    /// }
    /// ```
    fn as_any_mut(&mut self) -> &mut dyn std::any::Any;

    /// The core of this trait: get notified of changes happening in one or more [`DataStore`]s.
    ///
    /// This will be called automatically by the [`DataStore`] itself if the view has been
    /// registered: [`DataStore::register_view`].
    /// Or you might want to feed it [`StoreEvent`]s manually, depending on your use case.
    ///
    /// ## Example
    ///
    /// ```ignore
    /// fn on_events(&mut self, events: &[StoreEvent]) {
    ///     use re_arrow_store::StoreDiffKind;
    ///     for event in events {
    ///         match event.kind {
    ///             StoreDiffKind::Addition => println!("Row added: {}", event.row_id),
    ///             StoreDiffKind::Deletion => println!("Row removed: {}", event.row_id),
    ///         }
    ///     }
    /// }
    /// ```
    fn on_events(&mut self, events: &[StoreEvent]);
}

---

DataStore changelog PR series:

• DataStore changelog 1: let DataStores know about their StoreId #4202
• DataStore changelog 2: introduce StoreEvents #4203
• DataStore changelog 3: introduce StoreViews #4205
• DataStore changelog 4: add standalone "Custom StoreView" example #4206
• DataStore changelog 5: event-driven time histograms #4208
• DataStore changelog 6: event-driven EntityTree #4209

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 demo.rerun.io (if applicable)
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[Wumpf]

:chefkiss: 👌

[Wumpf]

looked it up and it is indeed https://docs.rs/lock_api/latest/lock_api/struct.RwLock.html
So it gotta be something else that's wrong here if you say we can't put the StoreView directly 🤔

[teh-cmc]

Yep, looked it up too, and ended up with the same emotion: 🤔

[Wumpf]

super-nit: This is your field not mine, but I thought the more technical correct term is transactional changes instead of atomic? Since the changes happen in one a single transaction but not necessarily atomic in the sense of an atomic operation

[Wumpf]

Right now one always subscribes to all DataStore, whether that's a good idea in the long run or not I don't know yet, but it seems the comment is incorrect as-is?

[teh-cmc]

super-nit: This is your field not mine, but I thought the more technical correct term is transactional changes instead of atomic? Since the changes happen in one a single transaction but not necessarily atomic in the sense of an atomic operation

Atomicity is a property of the query model, transactions are just one way of achieving it (case in point: we don't have transactions!).

[teh-cmc]

Right now one always subscribes to all DataStore, whether that's a good idea in the long run or not I don't know yet, but it seems the comment is incorrect as-is?

That's pretty much what I meant, I can replace with "all".

[Wumpf]

what's the intended use? I'd guess it's a display name used for debugging?

[Wumpf]

wondering if this isn't just always a &'static str, but would get annoying eventually

[teh-cmc]

what's the intended use? I'd guess it's a display name used for debugging?

Yeah, just a good habit for things to be named IME. Especially plugin-y stuff like this that ends up living all over the place.

[teh-cmc]

wondering if this isn't just always a &'static str, but would get annoying eventually

I would much prefer not forcing people to just through hoops if they need to format!() something (and we can turn to a Cow later if the string is a performance concern (highly unlikely)).

[Wumpf]

Don't understand why it's called with_ it's not like I get a DataStore with some handle. More like view or get_view?

[jleibs]

I assume this is because it doesn't return the view, but rather takes a closure that is executed with the view as an argument. As in "With this view, run this function". That said, I also find with_ confusing here. Maybe for_?

[teh-cmc]

I mostly based this on the thread_local API from the stdlib: https://doc.rust-lang.org/std/thread/struct.LocalKey.html#examples

[teh-cmc]

I'll keep it as is for now as it feels somewhat consistent with std at least... definitely feel free to change it later if you come up with anything better.