feat: cascade option on materialized view refresh

A view over a view could only be brought fully up to date by refreshing
each view in the lineage by hand, in order. `cascade` on the refresh
builder, Python `refresh`/`refresh_async` and Node `refresh` does that in
one call: every upstream view is refreshed furthest first, each reading
the version the one before it left, then the named view. `full` applies
to the named view only.

Locally the lineage is walked through each view's source, and each hop is
refreshed against the incarnation read in that walk. Remote tables send
`cascade` in the refresh request, only when set, so older servers that
reject unknown fields are unaffected by plain refreshes.
This commit is contained in:
Wyatt Alt
2026-09-24 19:09:12 +00:00
parent 604b1b583b
commit d96151c385
13 changed files with 297 additions and 33 deletions
+5 -1
View File
@@ -68,7 +68,9 @@ Recompute the view from its source.
The refresh is incremental when the source's changes can be reconciled
into the view -- rows added, changed or removed since the last one --
and otherwise rebuilds. `full` forces a rebuild; `sourceVersion`
refreshes to that source version instead of the latest.
refreshes to that source version instead of the latest. `cascade` first
refreshes every upstream view, furthest first, each reading the version
the one before it left; `full` applies to this view only.
Concurrent refreshes of one view do not duplicate its rows. Two that
plan the same source rows conflict on commit, and the loser throws
@@ -78,6 +80,8 @@ rather than writing them a second time.
* **options?**
* **options.cascade?**: `boolean`
* **options.full?**: `boolean`
* **options.sourceVersion?**: `number`