phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chinmay Kulkarni (Jira)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-5544) Dropping a base table with cascade with an older client does not clear all child view metadata
Date Fri, 25 Oct 2019 06:07:00 GMT

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

Chinmay Kulkarni updated PHOENIX-5544:
--------------------------------------
    Description: 
1) Start the HBase server with 4.15.0 Phoenix
2) Connect with a 4.14 client
3) Create a base table and a view on top of the base table:
{code:sql}
CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY, HOST VARCHAR(10),
FLAG BOOLEAN);

CREATE VIEW Z_VIEW1 (col1 INTEGER, col2 INTEGER, col3 INTEGER, col4 INTEGER, col5 INTEGER)
AS SELECT * FROM Z_BASE_TABLE WHERE ID>10;
{code}

4) Drop the base table with the cascade option:
{code:sql}
DROP TABLE Z_BASE_TABLE CASCADE;
{code}

5) Metadata for Z_VIEW1 is still there in SYSTEM.CATALOG and should be removed when trying
to recreate the same base table:
{code:sql}
CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY, HOST VARCHAR(10),
FLAG BOOLEAN);
{code}

6) This should remove the metadata for Z_VIEW1, but it does not. In fact, you can now query
Z_VIEW1 as if it was a valid view created on top of the new Z_BASE_TABLE, however there is
no parent->child link i.e.:
{code:sql}
SELECT * FROM SYSTEM.CATALOG WHERE LINK_TYPE=4;
{code}
--> Returns no results.

Effectively, Z_VIEW1 is sort of an "orphan" view with child->parent links but no parent->child
links. This is dangerous if a user wants to drop and recreate a base table, but views from
the previous lifetime of the base table can still be used to interact with the new base table.


  was:
1) Start the server with 4.15.0 Phoenix
2) Connect with a 4.14 client
3) Create a base table and a view on top of the base table:
{code:sql}
CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY, HOST VARCHAR(10),
FLAG BOOLEAN);

CREATE VIEW Z_VIEW1 (col1 INTEGER, col2 INTEGER, col3 INTEGER, col4 INTEGER, col5 INTEGER)
AS SELECT * FROM Z_BASE_TABLE WHERE ID>10;
{code}

4) Drop the base table with the cascade option:
{code:sql}
DROP TABLE Z_BASE_TABLE CASCADE;
{code}

5) Metadata for Z_VIEW1 is still there in SYSTEM.CATALOG and should be removed when trying
to recreate the same base table:
{code:sql}
CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY, HOST VARCHAR(10),
FLAG BOOLEAN);
{code}

6) This should remove the metadata for Z_VIEW1, but it does not. In fact, you can now query
Z_VIEW1 as if it was a valid view created on top of the new Z_BASE_TABLE, however there is
no parent->child link i.e.:
{code:sql}
SELECT * FROM SYSTEM.CATALOG WHERE LINK_TYPE=4;
{code}
--> Returns no results.

Effectively, Z_VIEW1 is sort of an "orphan" view with child->parent links but no parent->child
links. This is dangerous if a user wants to drop and recreate a base table, but views from
the previous lifetime of the base table can still be used to interact with the new base table.



> Dropping a base table with cascade with an older client does not clear all child view
metadata
> ----------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-5544
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5544
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.15.0, 5.1.0
>            Reporter: Chinmay Kulkarni
>            Assignee: Chinmay Kulkarni
>            Priority: Major
>             Fix For: 4.15.0, 5.1.0
>
>
> 1) Start the HBase server with 4.15.0 Phoenix
> 2) Connect with a 4.14 client
> 3) Create a base table and a view on top of the base table:
> {code:sql}
> CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY, HOST VARCHAR(10),
FLAG BOOLEAN);
> CREATE VIEW Z_VIEW1 (col1 INTEGER, col2 INTEGER, col3 INTEGER, col4 INTEGER, col5 INTEGER)
AS SELECT * FROM Z_BASE_TABLE WHERE ID>10;
> {code}
> 4) Drop the base table with the cascade option:
> {code:sql}
> DROP TABLE Z_BASE_TABLE CASCADE;
> {code}
> 5) Metadata for Z_VIEW1 is still there in SYSTEM.CATALOG and should be removed when trying
to recreate the same base table:
> {code:sql}
> CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY, HOST VARCHAR(10),
FLAG BOOLEAN);
> {code}
> 6) This should remove the metadata for Z_VIEW1, but it does not. In fact, you can now
query Z_VIEW1 as if it was a valid view created on top of the new Z_BASE_TABLE, however there
is no parent->child link i.e.:
> {code:sql}
> SELECT * FROM SYSTEM.CATALOG WHERE LINK_TYPE=4;
> {code}
> --> Returns no results.
> Effectively, Z_VIEW1 is sort of an "orphan" view with child->parent links but no parent->child
links. This is dangerous if a user wants to drop and recreate a base table, but views from
the previous lifetime of the base table can still be used to interact with the new base table.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message