You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR re-keys everything in the durable Catalog on `CatalogItemId`
instead of `GlobalId`, and shims everything above the durable Catalog
objects using two new methods `GlobalId::to_item_id()`, and
`CatalogItemId::to_global_id()`.
Now every item in the Catalog has the following fields:
* `id: CatalogItemId`, a stable _external_ identifier (i.e. in Catalog
tables like `mz_objects`) that is the same for the entire lifetime of
the object.
* `global_id: GlobalId`, a stable _internal_ identifier for this object
that can be used by storage and compute.
* `extra_versions: BTreeMap<Version, GlobalId>`, mapping of versions of
an object to the `GlobalId`s used by compute and storage to refer to a
specific version.
This de-coupling of `CatalogItemId` and `GlobalId` achieves two things:
1. Externally objects have a stable identifier, even as they are
`ALTER`-ed. This is required for external tools like dbt and Terraform
that track objects by ID.
2. Internally a `GlobalId` always refers to the same `RelationDesc` +
Persist Shard, this maintains the concept from the formalism that a
`GlobalId` is never re-assigned to a new pTVC.
The implementation of `ALTER TABLE ... ADD COLUMN ...` will thus
allocate a new `GlobalId` which will immutably refer to that specific
version of the table.
#### Other Changes
Along with `ItemKey` and `ItemValue` I updated the following Catalog
types:
* `GidMappingValue`: replaced the `id` field with `catalog_id` and
`global_id`, used to identify builtin catalog objects.
* `ClusterIntrospectionSourceIndexValue`: replaced the `index_id` field
with `catalog_id` and `global_id`, used to identify builtin
introspection source indexes.
* `CommentKey`: replaced `GlobalId` with `CatalogItemId`, used to
identify comments on objects.
* `SourceReferencesKey`: replaced `GlobalId` with `CatalogItemId`, used
to track references between a Source and the subsources/tables that read
from it.
#### Partial Progress
Today `CatalogItemId` is 1:1 with `GlobalId`, this allows us to
implement the `to_item_id` and `to_global_id` shim methods. Until we
support `ALTER TABLE ... ADD COLUMN ...` we can freely convert between
the two. This allows us to break this change up among multiple PRs
instead of a single massive change.
#### Initial Migration
Because `CatalogItemId` and `GlobalId` are currently 1:1, this allows us
to migrate the raw values of the IDs, e.g. `GlobalId::User(42)` becomes
`CatalogItemId::User(42)`, which is exactly what this PR does.
### Motivation
Progress towards
https://github.com/MaterializeInc/database-issues/issues/8233
Implements changes described in
#30019
### Tips for reviewer
This PR is split into two commits:
1. The durable catalog migration, and updates to durable Catalog
objects. I would appreciate the most thorough reviews on this commit.
4. Shimming all calling code to convert between `CatalogItemId` and
`GlobalId`.
### Checklist
- [ ] This PR has adequate test coverage / QA involvement has been duly
considered. ([trigger-ci for additional test/nightly
runs](https://trigger-ci.dev.materialize.com/))
- [ ] This PR has an associated up-to-date [design
doc](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/README.md),
is a design doc
([template](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/00000000_template.md)),
or is sufficiently small to not require a design.
<!-- Reference the design in the description. -->
- [ ] If this PR evolves [an existing `$T ⇔ Proto$T`
mapping](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/command-and-response-binary-encoding.md)
(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](https://github.com/MaterializeInc/cloud/pull/5021)).
<!-- Ask in #team-cloud on Slack if you need help preparing the cloud
PR. -->
- [ ] If this PR includes major [user-facing behavior
changes](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/guide-changes.md#what-changes-require-a-release-note),
I have pinged the relevant PM to schedule a changelog post.
0 commit comments