[SPARK-54119] Support METRIC_VIEW creation on V2 catalogs

[chenwang-databricks]

What changes were proposed in this pull request?

This PR extends metric-view support to DS v2 catalogs by routing CREATE VIEW ... WITH METRICS through the ViewCatalog / TableViewCatalog APIs introduced by SPARK-52729 and finalized by SPARK-56655. Third-party v2 catalogs that implement ViewCatalog can now host metric views with the same metadata fidelity as session-catalog metric views.

1. V2 metric-view CREATE path -- shared with CreateV2ViewExec. A new CreateV2MetricViewExec and CreateV2ViewExec both extend a new V2CreateViewPreparation trait (which itself extends V2ViewPreparation). The trait owns the shared CREATE-side run(): viewExists short-circuit on IF NOT EXISTS, createOrReplaceView for OR REPLACE, and cross-type collision decoding (ViewAlreadyExistsException -> tableExists -> EXPECT_VIEW_NOT_TABLE.NO_ALTERNATIVE). The metric-view subclass only supplies the metric-view-specific bits (no collation, schema-mode UNSUPPORTED, typed viewDependencies, PROP_TABLE_TYPE = METRIC_VIEW, retainColumnMetadata = true) via optional hooks on V2ViewPreparation. DataSourceV2Strategy intercepts CreateMetricViewCommand on a non-session catalog and routes to the new exec; the v1 session-catalog path stays in CreateMetricViewCommand.run.

2. First-class METRIC_VIEW table type.

• CatalogTableType.METRIC_VIEW is added alongside EXTERNAL / MANAGED / VIEW.
• TableSummary.METRIC_VIEW_TABLE_TYPE = "METRIC_VIEW" constant for the V2 surface.
• The previous view.viewWithMetrics property hack is removed; CatalogTable.isMetricView checks tableType == METRIC_VIEW directly.
• V1Table.summarizeTableType and V1Table.toCatalogTable(catalog, ident, ViewInfo) translate between the V2 property form and the V1 enum.
• HMS round-trip support: HiveTableType has no METRIC_VIEW variant (both regular views and metric views serialize as VIRTUAL_VIEW). HiveExternalCatalog now persists a view.subType = METRIC_VIEW property on write and lifts tableType back to METRIC_VIEW on read, so HMS-backed metric views survive the round trip.

3. Repo-wide tableType == VIEW audit. Promoting metric views to a distinct CatalogTableType opens silent regressions wherever existing code branches on VIEW. 15 sites updated to accept METRIC_VIEW alongside VIEW:

• DDL audit: CatalogTable.toJsonLinkedHashMap (DESCRIBE EXTENDED rows), HiveExternalCatalog.{createTable, alterTable, restoreTableMetadata} (4 sites for HMS-backed metric views), verifyAlterTableType in ddl.scala (so ALTER TABLE <metric_view> RENAME TO ... raises the right error category instead of silently renaming).
• Repo grep: SessionCatalog.isView, InMemoryCatalog.listViews, RelationResolution (streaming-on-view rejection), Analyzer.lookupTableOrView (ResolvedPersistentView wrapping), rules.scala (saveDataIntoView), DataStreamWriter (streaming write), DescribeRelationJsonCommand, AnalyzeColumnCommand, AnalyzePartitionCommand, CommandUtils.analyzeTable, and 3 sites in tables.scala (CREATE TABLE LIKE provider lookup, ALTER TABLE ADD COLUMNS, DESCRIBE PARTITION).
• Explicit rejection: SHOW CREATE TABLE on a metric view has no round-trippable CREATE VIEW ... WITH METRICS form, so it's rejected explicitly: the v1 session-catalog path raises the dedicated UNSUPPORTED_SHOW_CREATE_TABLE.ON_METRIC_VIEW; the v2 path is gated in DataSourceV2Strategy with unsupportedTableOperationError(...) (UNSUPPORTED_FEATURE.TABLE_OPERATION) before ShowCreateV2ViewExec would emit a misleading plain CREATE VIEW.

4. Drop-command parity.

• DropTableCommand (v1 path) treats both VIEW and METRIC_VIEW as views: DROP TABLE rejects either with wrongCommandForObjectTypeError, and DROP VIEW accepts either.
• V2SessionCatalog.dropTableInternal extends the existing "view rejected from DROP TABLE" guard to cover METRIC_VIEW.
• For non-session v2: DropTableExec (post-SPARK-56655) actively rejects with WRONG_COMMAND_FOR_OBJECT_TYPE ("Use DROP VIEW instead") when a view sits at the ident -- works unchanged for metric views since TableViewCatalog's default viewExists derives from loadTableOrView and recognizes MetadataTable + ViewInfo.
• ResolveSessionCatalog's DropView routing comment is clarified: v2 metric views fall through to DataSourceV2Strategy and ViewCatalog.dropView.

5. Typed view dependencies (ViewInfo.viewDependencies).

• New public DTOs in org.apache.spark.sql.connector.catalog: Dependency (sealed interface with Dependency.table(String...) / Dependency.function(String...) factories), TableDependency, FunctionDependency, DependencyList(Dependency[]).
• TableDependency and FunctionDependency carry the dependency identifier as structural multi-part name parts (record TableDependency(String[] nameParts)), not a single dot-flattened string. Arity is preserved per source so multi-level-namespace V2 catalogs (e.g. Iceberg cat.db1.db2.tbl -> 4 parts) and V1 sources without a catalog component (db.tbl -> 2 parts) round-trip without ambiguity against quoted identifiers containing literal ..
• DependencyList's canonical constructor and accessor defensively clone() the array so consumers can't mutate stored ViewInfo dependency state.
• ViewInfo gains a viewDependencies field and a ViewInfo.Builder.withViewDependencies(...) setter.
• MetricViewHelper.collectTableDependencies walks the analyzed plan and emits structural Seq[Seq[String]] parts (V1 sources via TableIdentifier.nameParts; V2 sources via (catalog.name +: namespace) :+ name).

6. Multi-level-namespace targets for v2 metric views. MetricViewHelper.analyzeMetricViewText previously required a TableIdentifier, capping the metric-view target at 3 name parts. v2 metric views with multi-level-namespace targets (e.g. cat.db1.db2.mv) failed at ident.asTableIdentifier with requiresSinglePartNamespaceError. The helper now takes nameParts: Seq[String] directly; call sites in both the v1 path (CreateMetricViewCommand) and the v2 path (DataSourceV2Strategy) updated.

7. metric_view.* descriptor properties. MetricView.getProperties produces canonical descriptive properties (metric_view.from.type, metric_view.from.name / metric_view.from.sql, metric_view.where) that the create path merges into the view's properties bag, so catalog browsers and tooling can inspect the source/filter without re-parsing the YAML body. Long values are truncated to Constants.MAXIMUM_PROPERTY_SIZE; the Scaladoc on getProperties calls out that metric_view.from.sql is therefore a descriptive value, not a round-trippable representation -- consumers should re-read the YAML body for the full SQL.

8. ViewInfo constructor cleanup. The metric-view-specific PROP_TABLE_TYPE = METRIC_VIEW special case is dropped from the generic ViewInfo constructor in favor of properties().putIfAbsent(...). Callers that want a more specific kind (e.g. METRIC_VIEW) call BaseBuilder.withTableType(...) before build() -- exercised by CreateV2MetricViewExec via the new V2ViewPreparation.tableType hook.

9. ViewHelper.aliasPlan(retainMetadata). The user-specified-column-with-comment branch in aliasPlan previously dropped existing column metadata. A new retainMetadata: Boolean = false parameter merges the analyzed attribute's metadata into the new comment metadata. ViewHelper.prepareTable passes retainMetadata = isMetricView (v1 path); V2ViewPreparation exposes a retainColumnMetadata hook that CreateV2MetricViewExec overrides to true (v2 path). Both preserve the per-column metric_view.type / metric_view.expr keys that the analyzer attaches to dimensions and measures even when the user renames columns and adds comments.

10. Error classes.

• New INVALID_METRIC_VIEW_YAML (sqlState 42K0L). MetricViewPlanner.parseYAML's catch blocks now route through QueryCompilationErrors.invalidMetricViewYamlError instead of SparkException.internalError, so a typo in the user's YAML body surfaces as a user-correctable AnalysisException rather than "please contact support".
• New UNSUPPORTED_SHOW_CREATE_TABLE.ON_METRIC_VIEW (sqlState 0A000) for the v1 session-catalog path.

11. Misc.

• MetricViewCanonical.parseSource accepts multipart identifiers (parseMultipartIdentifier) so 3-part catalog.schema.table source references work as AssetSource.

Why are the changes needed?

Before this PR, metric-view DDL only worked against the session catalog: the create path called SessionCatalog.createTable directly, and there was no way for a third-party v2 catalog (Unity Catalog, Hive Metastore catalog, custom REST catalogs, etc.) to own a metric view's lifecycle. SPARK-52729 / SPARK-56655 shipped ViewCatalog and TableViewCatalog as the public v2 surface for catalog-managed views; metric views are a kind of view and naturally belong on this surface.

Once metric views can live on a v2 catalog, two more constraints surface:

1. Type discriminator. A consumer reading a row through ViewCatalog.loadView needs to know it's a metric view, not a plain SQL view, so it can render the right UI / planner output. Encoding this in PROP_TABLE_TYPE = METRIC_VIEW keeps the distinction wire-compatible and lets V1Table.toCatalogTable reconstruct CatalogTableType.METRIC_VIEW on the read path.
2. Structured dependency lineage. Metric views always reference at least one source table; cataloging that lineage as flat string properties or single dot-joined strings loses arity for multi-level namespaces and is ambiguous against quoted identifiers. A typed DependencyList of TableDependency / FunctionDependency with structural String[] nameParts lets catalogs persist the lineage as a first-class field with full fidelity.

The remaining changes (drop-command parity, aliasPlan metadata retention, metric_view.* properties, parseMultipartIdentifier, tableType == VIEW audit, multi-level-namespace lift, HMS round-trip marker) are mechanical follow-ups that fall out of supporting metric views as a real CatalogTableType and as a v2 catalog citizen -- without them, basic operations like DROP VIEW, DESCRIBE TABLE EXTENDED, CREATE VIEW (a COMMENT 'c') WITH METRICS ..., or CREATE VIEW cat.db1.db2.mv WITH METRICS ... would silently degrade.

Does this PR introduce any user-facing change?

Yes, both for end users and for catalog plugin developers:

End users:

• CREATE VIEW <ident> WITH METRICS ... now works against any v2 catalog that implements ViewCatalog, including catalogs with multi-level namespace targets. Previously it was rejected with MISSING_CATALOG_ABILITY.VIEWS for non-session catalogs, and capped at single-level namespaces. IF NOT EXISTS and OR REPLACE are honored on the v2 path (regression vs. v1 fixed).
• A v2 metric view can be queried with SELECT region, measure(count_sum) FROM <mv> ..., dropped with DROP VIEW, listed via SHOW VIEWS (and via SHOW TABLES on a TableViewCatalog, matching v1 SHOW TABLES output), and described with DESCRIBE TABLE / DESCRIBE TABLE EXTENDED. DROP TABLE on a metric view throws WRONG_COMMAND_FOR_OBJECT_TYPE ("Use DROP VIEW instead").
• SHOW CREATE TABLE on a metric view throws an explicit unsupported-feature error (no round-trippable form yet).
• Session-catalog metric views are now stored as CatalogTableType.METRIC_VIEW instead of CatalogTableType.VIEW + view.viewWithMetrics=true. Observable in DESCRIBE TABLE EXTENDED's Type row and the tableType column of the tables system table. SQL behavior is unchanged. Hive-metastore-backed metric views also round-trip through HMS via a view.subType = METRIC_VIEW property marker.
• Error messages from DROP TABLE / DROP VIEW mismatch now mention METRIC_VIEW alongside VIEW.
• Malformed metric-view YAML now surfaces as INVALID_METRIC_VIEW_YAML (user-correctable) instead of "Spark internal error, please contact support".

Catalog plugin developers:

• New public API surface in org.apache.spark.sql.connector.catalog: sealed interface Dependency with permits TableDependency, FunctionDependency, both records carrying String[] nameParts. DependencyList(Dependency[]) with defensive copy. All @Evolving, @since 4.2.0.
• ViewInfo gains a typed viewDependencies() accessor and ViewInfo.Builder.withViewDependencies(...) setter.
• TableSummary.METRIC_VIEW_TABLE_TYPE = "METRIC_VIEW" constant.
• CatalogTableType.METRIC_VIEW enum value (v1 surface).
• V2ViewPreparation (private to org.apache.spark.sql.execution.datasources.v2) gains optional viewDependencies / tableType / retainColumnMetadata hooks.

How was this patch tested?

MetricViewV2CatalogSuite -- 30 tests across 5 sections, all against an in-memory ViewCatalog test fixture (MetricViewRecordingCatalog extends InMemoryTableCatalog with TableViewCatalog):

Section 1 -- CREATE-related (11 tests):

• V2 catalog receives METRIC_VIEW table type and view text via ViewInfo.
• V2 catalog path populates metric_view.* descriptor properties + view context (currentCatalog / currentNamespace) + captured SQL configs.
• V2 catalog path captures SQLSource and comment.
• Metric view columns carry metric_view.type / metric_view.expr in column metadata.
• User-specified column names with comments preserve metric_view.* metadata (pins the aliasPlan(retainMetadata = true) fix).
• CREATE OR REPLACE VIEW ... WITH METRICS replaces an existing v2 metric view (asserts on the replacement's distinguishing fields: queryText, metric_view.where, dependencies).
• CREATE VIEW IF NOT EXISTS ... WITH METRICS is a no-op when the view exists (catalog never sees the second createView call).
• CREATE VIEW ... WITH METRICS over a v2 table at the ident throws TABLE_OR_VIEW_ALREADY_EXISTS (analyzer-time pre-check).
• CREATE VIEW IF NOT EXISTS ... WITH METRICS is a no-op when a v2 table sits at the ident (v1 parity).
• CREATE VIEW ... WITH METRICS on a non-ViewCatalog catalog fails with MISSING_CATALOG_ABILITY.VIEWS.
• CREATE VIEW ... WITH METRICS at a multi-level-namespace v2 target (testcat.ns_a.ns_b.mv_deep) succeeds (pins the analyzeMetricViewText lift to Seq[String]).

Section 2 -- Dependency extraction (5 tests):

• SQL source JOIN captures both tables as 3-part nameParts.
• SQL source subquery deduplicates same-table references.
• SQL source self-join deduplicates same-table references.
• V1 session-catalog source emits 2-or-3-part nameParts.
• Multi-level V2 namespace source (testcat.ns_a.ns_b.events_deep) emits 4-part nameParts.

Section 3 -- SELECT cases (5 tests, modeled on MetricViewSuite patterns):

• SELECT measure(count_sum) FROM <mv> GROUP BY region returns aggregated rows (exercises the full loadTableOrView -> MetadataTable(ViewInfo) -> V1Table.toCatalogTable(ViewInfo) -> ResolveMetricView round-trip).
• SELECT measure(...) WHERE region = ... -- query-layer filter on top of the view.
• View's pre-defined where clause is applied (where = Some("count > 1") filters at view-resolution time).
• Multiple measures with different aggregations (sum / sum / max).
• ORDER BY measure(...) DESC LIMIT 1 over the metric view.

Section 4 -- DESCRIBE cases (2 tests):

• DESCRIBE TABLE EXTENDED round-trips through loadTableOrView and emits the View Text / Type rows (gated through the CatalogTable.toJsonLinkedHashMap VIEW gate, which now accepts METRIC_VIEW).
• DESCRIBE TABLE (non-EXTENDED) returns the aliased columns.

Section 5 -- DROP / SHOW cases (7 tests):

• DROP VIEW succeeds on a v2 metric view.
• DROP VIEW IF EXISTS on a non-existent v2 metric view is a no-op.
• DROP TABLE on a v2 metric view throws WRONG_COMMAND_FOR_OBJECT_TYPE ("Use DROP VIEW instead", per SPARK-56655's DropTableExec) and asserts the metric view is not deleted.
• DROP TABLE IF EXISTS on a v2 metric view also throws (IF EXISTS doesn't silence the wrong-type error, v1 parity).
• SHOW CREATE TABLE on a v2 metric view throws UNSUPPORTED_FEATURE.TABLE_OPERATION with operation "SHOW CREATE TABLE".
• SHOW TABLES on a TableViewCatalog lists both tables and metric views (matches v1 SHOW TABLES output per SPARK-56655).
• SHOW VIEWS lists v2 metric views.

Existing session-catalog metric-view tests (MetricViewSuite, SimpleMetricViewSuite, HiveMetricViewSuite) and v1 path tests pass unchanged. DDLSuite and HiveDDLSuite had their tableTypes enumerations updated to include METRIC_VIEW in two assertion lists.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Cursor (Claude Sonnet 4.7)

[cloud-fan]

Thanks for extending metric views to v2 catalogs. The shape of the change is right — route through ViewCatalog.createView with PROP_TABLE_TYPE = METRIC_VIEW and a typed viewDependencies, and promote METRIC_VIEW to a first-class CatalogTableType. A few significant concerns:

1. v2 path forks instead of reusing V2ViewPreparation and changes behavior on IF NOT EXISTS / OR REPLACE. CreateMetricViewCommand.createMetricViewInV2Catalog is open-coded inside a v1 RunnableCommand and duplicates most of V2ViewPreparation.buildViewInfo, but with materially different behavior: allowExisting and replace are silently dropped on the v2 path (regression vs. v1, which honored ignoreIfExists), there's no viewExists short-circuit, no createOrReplaceView, no cross-type collision decoding (so a table sitting at the ident leaks ViewAlreadyExistsException instead of unsupportedCreateOrReplaceViewOnTableError), and the CharVarcharUtils / SchemaUtils.checkColumnNameDuplication / checkIndeterminateCollationInSchema / owner-stamping work that V2ViewPreparation does is missing. Refactoring this into a CreateV2MetricViewExec (or extending V2ViewPreparation with a viewDependencies / extraProperties hook) plus a DataSourceV2Strategy rule would close all of these gaps in one move.

2. Audit other tableType == VIEW gates for METRIC_VIEW. Promoting metric views to a distinct CatalogTableType opens up silent regressions wherever existing code branches on VIEW. Two I'm fairly sure about: CatalogTable.toJsonLinkedHashMap (interface.scala:670) gates View Text / View Original Text / View Schema Mode / View Catalog and Namespace / SQL Path on tableType == VIEW, so DESCRIBE TABLE EXTENDED on a metric view will lose all of those rows — visible regression vs. the pre-PR viewWithMetrics storage. And HiveExternalCatalog.{createTable, alterTable, restoreTableMetadata} (lines 277, 297, 598, 838) only special-case VIEW, so a Hive-metastore-backed session-catalog metric view will go through the wrong branches on persist and read-back. Tests don't cover Hive-backed metric views, so this would only surface in production. Worth grepping tableType == CatalogTableType.VIEW and tableType == VIEW repo-wide and deciding which sites also need to accept METRIC_VIEW.

3. TableDependency.tableFullName is a single dot-joined string but the Javadoc claims a fixed three-part shape. This breaks down two ways: (a) MetricViewHelper.collectTableDependencies uses unquotedString for V1 sources, which yields a 2-part db.tbl whenever TableIdentifier.catalog is unset, and mkString(".") for V2 sources, which yields N-part names for catalogs with multi-level namespaces (e.g., Iceberg cat.db1.db2.tbl is 4 parts) — so the producer doesn't honor the contract; (b) any consumer parsing the string back via split/join loses arity and is ambiguous against quoted identifiers containing a literal .. Since this is brand-new public API, it's the right time to make the storage structural — e.g., TableDependency(String[] nameParts) — rather than committing to a string the producer can't always honor.

4. MetricViewPlanner.parseYAML raises SparkException.internalError for malformed user YAML. Replacing invalidLiteralForWindowDurationError is right, but internalError is the wrong category — a typo in the user's YAML body shouldn't surface as "Spark internal error, please contact support." Should be a QueryCompilationErrors / AnalysisException with a real error class.

Minor stuff (typed DTO sealing/mutability, the ViewInfo constructor's metric-view special case, missing tests for OR REPLACE / IF NOT EXISTS / V1-source dependency / multi-level-namespace V2 source / read-back through loadRelation) is in the inline comments below.

[cloud-fan]

Round 2 review.

Status: 13 prior findings addressed (4 main concerns + 9 inline), 0 remaining, 4 new (3 newly introduced in commits since the prior review at 8f62efc6, 1 late catch). The shared V2ViewPreparation / V2CreateViewPreparation refactor reads cleanly, the typed Dependency / DependencyList API replaces the dot-joined-string form, the INVALID_METRIC_VIEW_YAML error is in place, and the tableType == VIEW audit covers most sites. Four follow-ups inline.

[cloud-fan]

Round 3 review.

Status: All 4 prior findings addressed (verifyAlterTableType audit miss, StructField/Column public-API split, Column.fromStructField comment-duplication via revert, multi-level namespace lift in analyzeMetricViewText), 0 remaining, 7 new (1 newly introduced, 6 late catches). The round 3 follow-up commit cleanly addresses the round 2 findings; remaining concerns center on v1/v2 inconsistencies (descriptive properties, error class, dependency-name arity) and API correctness of the new Dependency records.

I'll be honest about the 6 late catches: most have been latent since round 1 — the structural-form switch fixed the format dimension I flagged but not the arity dimension; the records I suggested have a value-semantics issue I missed; the metric_view.* merge has been on the v2 path since the original PR. Apologies for not surfacing these earlier.

[cloud-fan]

The v2 path merges metric_view.from.type / metric_view.from.name / metric_view.from.sql / metric_view.where into the property bag here (properties ++ metricView.getProperties), but the v1 path in CreateMetricViewCommand.createMetricViewInSessionCatalog (metricViewCommands.scala:74-78) passes properties to prepareTable without the merge. Result: DESCRIBE TABLE EXTENDED on a session-catalog metric view doesn't show these descriptor rows; on a v2 metric view, it does.

The PR description states the merge happens "into the view's properties bag" without a v1/v2 carve-out — please confirm this is intentional, or merge in v1 too.

[cloud-fan]

The v1 path uses the dedicated UNSUPPORTED_SHOW_CREATE_TABLE.ON_METRIC_VIEW (tables.scala:1219 → showCreateTableNotSupportedOnMetricViewError); this v2 path uses the generic UNSUPPORTED_FEATURE.TABLE_OPERATION. Same user action, two error classes — the dedicated one carries a more actionable message ("not supported on metric view"). showCreateTableNotSupportedOnMetricViewError takes a String; you can format the multipart name the same way the case below does ((catalog.name() +: ident.asMultipartIdentifier).map(quoteIfNeeded).mkString(".")).

[cloud-fan]

TableIdentifier.nameParts returns 1, 2, or 3 parts depending on which of catalog / database are set on the resolved CatalogTable.identifier. The same v1 source table can yield [db, tbl] or [spark_catalog, db, tbl] across runs — the test in MetricViewV2CatalogSuite (the V1 source dependency-extraction test) admits this with parts.length >= 2 && parts.length <= 3. The TableDependency Javadoc (TableDependency.java:32-33) acknowledges it, but downstream consumers comparing dependency names structurally won't be able to rely on stable arity. Same issue applies to the View arm (line 105) and HiveTableRelation arm (line 112).

Consider normalizing v1 sources to always emit 3-part [spark_catalog, db, tbl] (prepending the session-catalog name when missing) so consumers see a stable shape per source kind. The test should then assert exactly 3 parts.

[cloud-fan]

MetricViewHelper.analyzeMetricViewText (called on line 345) already parses the YAML internally via MetricViewPlanner.parseYAML → MetricViewFactory.fromYAML. Re-parsing here duplicates the work. analyzeMetricViewText could return (LogicalPlan, MetricView) (or expose the parsed MetricView via the MetricViewPlaceholder it builds) so the strategy doesn't pay the parse twice.

[cloud-fan]

Extracting r.catalog.asTableCatalog into tableCatalog is a no-op refactor unrelated to metric-view support and is not mentioned in the PR description. Please revert or split into a separate cleanup PR — keeps the metric-view PR focused.

[cloud-fan]

Java records auto-generate equals/hashCode from per-field Objects.equals/Objects.hashCode, which on array fields fall through to Object.equals (reference equality). So DependencyList.of(Dependency.table("a","b")).equals(DependencyList.of(Dependency.table("a","b"))) == false. Same issue on TableDependency.nameParts (TableDependency.java:42) and FunctionDependency.nameParts (FunctionDependency.java:34).

This undermines the "structural multi-part name" intent — consumers can't dedup, compare, or use these as Map keys. Please override equals/hashCode to use Arrays.equals/Arrays.hashCode on each record (and Arrays.deepEquals/Arrays.deepHashCode on DependencyList), or expose List<...> instead of [] to inherit value semantics for free.

[cloud-fan]

Two test comments describe behavior in terms of the in-PR change rather than the current invariant — they age poorly post-merge:

• Lines 253-254: // ... Without the retainMetadatafix toViewHelper.aliasPlan, the metric_view.* keys disappear here. — once merged, there is no "fix" to refer to. Rephrase as a pin: // Pins aliasPlan(retainMetadata=true): metric_view.* keys must survive a column rename with comments.
• Lines 749-752 (DESCRIBE EXTENDED test): // The "Type" row was added alongside this metric-view PR so DescribeV2ViewExec matches v1 parity... — same problem. Rephrase to describe the current invariant being pinned (e.g. DescribeV2ViewExec emits a "Type" row matching v1 parity, so users can distinguish VIEW vs METRIC_VIEW.).