Skip to content

Conversation

@teskje
Copy link
Contributor

@teskje teskje commented Nov 20, 2025

Motivation

Tips for reviewer

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

This commit changes the storage controller's data structures to support
specifying a "view" storage collection, i.e., a storage collection that
points to the same persist shard as another, for other data sources than
`Table`. The intent is specifically to get support for
`DataSource::Other`, in preparation for `ALTER MATERIALIZED VIEW`.

Rather than adding a `primary` field to the `DataSource::Other` variant,
this commit instead moves the `primary` field out of `DataSource::Table`
and into `CollectionDescription`. This reflects the fact that the
"primary" concept is independent of the data source, even though it's
currently only used for tables. It also removes some visual clutter.
@teskje teskje force-pushed the replacement-mvs branch 2 times, most recently from 6fb0f85 to eba1d14 Compare November 21, 2025 15:14
When applying an item `StateUpdate`, we had an optimization that would
skip parsing the `create_sql` if it hadn't change, and reuse the old
`CatalogEntry` instead. This produces the wrong outcome if the
`extra_versions` change without the SQL changing: Any version updates
are not reflected in the new `CatalogEntry`.

To fix this, this commit removes the optimization, under the assumption
that DDL is sufficiently rare that we can live without it. If that turns
out not the be the case, we can keep the optimization and refine the
conditions under which SQL parsing is performed, though that seems
brittle.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant