[jira] [Updated] (PHOENIX-7951) Transforming a table that already has a view promotes the view's column onto the base table

["Viraj Jasani (Jira)" <ji...@apache.org>]

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

Viraj Jasani updated PHOENIX-7951:
----------------------------------
    Fix Version/s: 5.3.3
                       (was: 5.3.2)

> Transforming a table that already has a view promotes the view's column onto the base table
> -------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-7951
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-7951
>             Project: Phoenix
>          Issue Type: Bug
>          Components: core
>            Reporter: Andrew Kyle Purtell
>            Assignee: Andrew Kyle Purtell
>            Priority: Major
>             Fix For: 5.4.0, 5.3.3
>
>
> After transforming a base table that already has {{view1(VIEW_COL1)}}, creating a second view {{view2(VIEW_COL1)}} fails with a duplicate column error:
> {noformat}
> TransformMonitorIT.testTransformMonitor_tableWithViews_OnOldAndNew:766
>   org.apache.phoenix.schema.ColumnAlreadyExistsException: ERROR 514 (42892):
>   ... columnName=VW2_<...>.VIEW_COL1
>     at PTableImpl$Builder.initDerivedAttributes(PTableImpl.java:845)
>     at PTableImpl$Builder.build(PTableImpl.java:949)
>     at MetaDataClient.createTableInternal(MetaDataClient.java:3898)
>     at MetaDataClient.createTable(MetaDataClient.java:1073)
>     at TransformMonitorIT.testTransformMonitor_tableWithViews_OnOldAndNew(TransformMonitorIT.java:766)
> {noformat}
> Two sibling views each declaring their own {{VIEW_COL1}} should be fine, but the intervening transform leaks {{VIEW_COL1}} into the base table's resolved column set.
> {{TransformClient.addTransform(...)}} builds the new physical table from the source table's full column list and then re-links the existing child views to the new physical table. The combination of {{setAllColumns(...)}} for the new physical table plus the child view re-linking causes the preexisting {{view1.VIEW_COL1}} to be resolved as part of the base table after the transform, so a later {{CREATE VIEW view2 (VIEW_COL1 ...)}} sees a duplicate when {{PTableImpl$Builder.initDerivedAttributes}} aggregates parent + declared columns.
> Proposed fix:
> Ensure the staged new physical table is materialized with only the base table's own columns, excluding view-only/derived columns, and that re-linking child views does not attribute view only columns to the base table's resolved schema. Needs validation that legitimate view-inherited columns still resolve correctly.



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