propagate attr keys to live views

[TeunHuijben]

Note: this is a PR to @cmalinmayor's graph-view PR!

Propagate new attribute keys to live views

Builds on royerlab#325 (graph-views).

royerlab#325 makes a view follow its root for attribute writes and node adds, but not for add_node_attr_key / add_edge_attr_key. So a view created before the key was registered never learns about it, and the write that royerlab#325 propagates back into that view gets rejected:

root = SQLGraph(drivername="sqlite", database=..., overwrite=True)
root.add_node_attr_key("area", default_value=0.0, dtype=pl.Float64)
root.add_node({"t": 0, "area": 1.0})

view = root.filter().subgraph()                                   # live view exists
root.add_node_attr_key("foo", default_value=-1, dtype=pl.Int64)   # reports success
root.update_node_attrs(attrs={"foo": [7]}, node_ids=[root.node_ids()[0]])
# ValueError: Node attribute key 'foo' not found in graph. Expected '['t', 'area']'

The root is fine; the error comes from the view's local store. Only SQLGraph roots hit this. A rustworkx-rooted view shares the root's attribute dicts and reports the root's key list, so it picks new keys up for free.

Same problem when registering through one view: its siblings never see the key.

What changed

• BaseGraph._maintain_views_attr_key, the schema counterpart of the existing _maintain_views_node_attrs, called from add_node_attr_key / add_edge_attr_key in SQLGraph and RustWorkXGraph.
• GraphView._apply_root_attr_key holds the local backfill that used to be inlined in GraphView.add_node_attr_key / add_edge_attr_key. Those now just delegate to the root, so registering through a view takes the same path and reaches the sibling views too.
• Three tests in test_subgraph.py, parametrized over all backends.

The rustworkx call sites look redundant since _apply_root_attr_key returns early for rustworkx roots, but they aren't: a view built with an explicit node_attr_keys still needs the new key appended to that pinned list. The old inline code did that append unconditionally, so the append happens before the early return.

Costs nothing on the hot paths — this only runs on add_*_attr_key, which on SQL already does an ALTER TABLE.

Not covered

remove_node_attr_key / remove_edge_attr_key have the mirror-image gap: a key removed on the root is still reported by existing views. Left out of this PR; happy to do it here if you'd rather have the schema path symmetric in one go.

[TeunHuijben]

@cmalinmayor, I somehow cannot ask you to review this, because it is your own fork. So therefore this message 😊✋

[cmalinmayor]

🍅