[jira] [Resolved] (SPARK-58604) ALTER VIEW on a v2 ViewCatalog drops the view's dependency list

["Wenchen Fan (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SPARK-58604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wenchen Fan resolved SPARK-58604.
---------------------------------
    Fix Version/s: 4.3.0
       Resolution: Fixed

Issue resolved by pull request 57802
[https://github.com/apache/spark/pull/57802]

> ALTER VIEW on a v2 ViewCatalog drops the view's dependency list
> ---------------------------------------------------------------
>
>                 Key: SPARK-58604
>                 URL: https://issues.apache.org/jira/browse/SPARK-58604
>             Project: Spark
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 5.0.0
>            Reporter: Szehon Ho
>            Assignee: Szehon Ho
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 4.3.0
>
>
> {{CatalogV2Util.viewInfoBuilderFrom}} seeds a {{View.Builder}} from an existing view so that ALTER VIEW execs can override the one field that changes and leave every other field untouched. It copies the schema, properties, query text, SQL configs, current namespace, current catalog, query column names and schema mode -- but it does not copy the typed {{viewDependencies}} field.
> All three callers 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 {{ALTER VIEW ... SET TBLPROPERTIES}} drops them.
> Fix: carry {{viewDependencies}} through in {{viewInfoBuilderFrom}}, consistent with how the other nullable fields ({{currentCatalog}}, {{schemaMode}}) are already handled.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org