Make graph views attributes live-update

[cmalinmayor]

Add an option for what mode the view is in:

• Write through (existing, default behavior) - attribute updates propagate to root and are written to the current view, but don't get updates from sibling views
• Live - attribute updates are written to root, and this view is registered with the root to stay synchronized with any updates to the root
  For a totally detached view, just call subgraph and detach.

Every Live view adds work for the root update, regardless of listeners on the view. Write-through views do not, and are fully updated in the case where there is a single view, so they are preferred for any use case other than multi-view synchronization.

Next steps:

• add structural updates (adding or removing nodes or edges) to the live view updates - my next step
• Simplify/clarify what "sync" means - I left all references as intact as possible, other than requiring LIVE views to always "sync", since I wasn't quite sure what sync=False meant
• Live filtering/dynamic membership based on attribute values

[TeunHuijben]

@cmalinmayor, I pushed a fix to a bug that was introduced in this branch, namely:

A view does not necessarily contain all node|edge attributes that the root contains. When the attributes in the view are updated because they come from the root, we should check which attributes are actually present on the view, as implemented in my last commit.

Details:

_apply_root_node_attrs and _apply_root_edge_attrs forwarded every changed key into the view's local store. A view built with an explicit node_attr_keys/edge_attr_keys has no local column for the keys it left out, so the write was rejected:

ValueError: Node attribute key 'bar' not found in graph.
            Expected '['t', 'area']'

Intersect the changed keys with the view's own key list before writing through. Only affects views over a non-rustworkx root; a rustworkx-rooted view shares the root's attribute dicts and never takes this path.

[TeunHuijben]

@cmalinmayor, I made this PR more "symmetric" by also propagating the removal of node|edge attributes (remove_node|edge_attr_key) from the root to all its views

[TeunHuijben]

Point of concern is the regression in the benchmarks (across all backends), because keeping views up to date is just expensive and will always be slower compared to not doing it...

bit deeper:
GraphMutationsBenchmark.setup() always adds a listener to the view. Before, this was harmless because operations on the root didn't care about viewers/listeners. However, it now does, and every test that was intended only to test something on a root without views/listeners is slower because of this listener. Claude suggests to put listened_view into its own benchmark class, so it only runs for the listener benchmark

[TeunHuijben]

Hi @JoOkuma, from a motile_tracker perspective, this PR does what we want it to do. Can you have a look and let me know what we need to change to have it ready to merge? 🙏

[JoOkuma]

Hi @cmalinmayor, thanks for the major cleanup and organization of the codebase you have done with this PR.

I opened cmalinmayor#2 with some changes. Can you review it?

I'm worried about the runtime with listeners, as the benchmark shows.

What do you think of having the communication from root to views off by default?
If we go for that, I think I can also refactor what sync means in GraphView and its behavior.

[cmalinmayor]

class ViewMode(Enum):
    """
    How a `GraphView` relates to its root graph after creation.

    UNLINKED
        No relationship to the root at all: never registers with it, so it is
        invisible to the root's per-write maintenance -- writing to the root,
        or to any other view, costs nothing extra because this view exists.
        Writing through this view (`update_node_attrs`, `add_node`, etc.)
        never touches the root either: it behaves like a plain, independent
        `RustWorkXGraph` that happens to remember where it came from.
    WRITE_THROUGH
        Does not register with the root either, so it is still invisible to
        the root's per-write maintenance and stays silently stale with
        respect to writes made elsewhere (directly on the root, or through a
        sibling view). It stays current for its own writes only: writing
        through this view (`update_node_attrs`, `add_node`, etc.) writes the
        root and then patches this view's own local copy in the same call,
        matching the view's pre-registration behavior.
    LIVE
        Registers with the root (`root._views`). The root pushes every write
        -- from anywhere -- into this view, so it is always current, at the
        cost of the root doing maintenance work for this view on every write
        regardless of whether anything is listening. The
        only mode that keeps a view consistent with writes made outside of
        it.
    """

    UNLINKED = "unlinked"
    WRITE_THROUGH = "write_through"
    LIVE = "live"

Started to workshop this and hit enough edge cases that it was worth getting feedback before I went further. Is this like what you were thinking @JoOkuma ?

[cmalinmayor]

(Noticed that we didn't wire up any actual changes to graph structure yet, just attributes, but we will need that for multi-user edits, and I don't think it's a huge change once we decide on the framework)

[JoOkuma]

@cmalinmayor, yes, that's exactly it.

There are a few edge cases with graph structure that are ambiguous. For example, when you delete an element of the subgraph, are they deleted from the root graph or not (if we assume it's a candidate graph, "not" is the right answer)?

[cmalinmayor]

@JoOkuma I think I added back in the old behavior without any performance regressions and with the same functionality 🤞

[JoOkuma]

Hi @cmalinmayor, I'm back from a few days off. I gotta catch up with work, and I'll review this in a few days.

[JoOkuma]

LGTM, @cmalinmayor. Thanks for your patience.

[TeunHuijben]

Thanks @JoOkuma!!