szehon-ho opened a new pull request, #57802:
URL: https://github.com/apache/spark/pull/57802
### What changes were proposed in this pull request?
`CatalogV2Util.viewInfoBuilderFrom` seeds a `View.Builder` from an existing
view so ALTER VIEW execs can override the one field that changes and leave
everything else untouched. It copies the schema, properties, query text, SQL
configs, current namespace, current catalog, query column names and schema mode
— but not the typed `viewDependencies` field.
This PR carries `viewDependencies` through, consistent with how the other
nullable fields (`currentCatalog`, `schemaMode`) are already handled.
### Why are the changes needed?
All three callers of `viewInfoBuilderFrom` are metadata-only mutations that
do not change the view body:
- `AlterV2ViewSetPropertiesExec` (`ALTER VIEW ... SET TBLPROPERTIES`)
- `AlterV2ViewUnsetPropertiesExec` (`ALTER VIEW ... UNSET TBLPROPERTIES`)
- `AlterV2ViewSchemaBindingExec` (`ALTER VIEW ... WITH SCHEMA ...`)
Each rebuilds the payload and calls `ViewCatalog.replaceView`, so after any
of them the catalog receives a `View` whose `viewDependencies()` is `null` and
the previously recorded dependency list is silently lost. Dependency lists are
a first-class field on `View` rather than an encoded string property precisely
because their nested structure does not round-trip through flat properties, so
a catalog has no other way to recover them.
This is reachable today through metric views, which are the only producer of
dependencies (`CreateV2MetricViewExec`). Creating a metric view records its
source tables, and a subsequent property change drops them:
```sql
CREATE VIEW mv WITH METRICS LANGUAGE YAML AS $$ ... $$; -- dependencies
recorded
ALTER VIEW mv SET TBLPROPERTIES ('k' = 'v'); -- dependencies now
null
```
### Does this PR introduce _any_ user-facing change?
No, in the sense that no released version is affected — the `View` API and
these ALTER VIEW execs are new in the unreleased line, so this is a fix within
master rather than a change in behavior users have depended on. Catalogs that
persist view lineage will now keep it across a metadata-only ALTER VIEW instead
of seeing it cleared.
### How was this patch tested?
Two new tests, both confirmed to fail before the fix and pass after:
- `CatalogV2UtilSuite`: `viewInfoBuilderFrom` preserves a dependency list,
and leaves an absent one absent (guards the null path). The first fails without
the fix.
- `MetricViewV2CatalogSuite`: end-to-end `ALTER VIEW <metric_view> SET
TBLPROPERTIES` against the recording `RelationCatalog`, asserting the
replacement payload still carries the source-table dependency. Without the fix
this fails with `viewDependencies()` being `null`.
Full suites pass locally: `CatalogV2UtilSuite` (10 tests) and
`MetricViewV2CatalogSuite` (32 tests). `./dev/lint-scala` passes.
### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Cursor (Opus 5)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
