[jira] [Resolved] (HIVE-21125) Hive does not check for dependent materialized views when issuing a DROP TABLE command

["Taylor Cox (JIRA)" <ji...@apache.org>]

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

Taylor Cox resolved HIVE-21125.
-------------------------------
    Resolution: Invalid

Looks like this fix is checked into Hive 3.2. Backporting is a separate discussion.

> Hive does not check for dependent materialized views when issuing a DROP TABLE command
> --------------------------------------------------------------------------------------
>
>                 Key: HIVE-21125
>                 URL: https://issues.apache.org/jira/browse/HIVE-21125
>             Project: Hive
>          Issue Type: Bug
>          Components: Materialized views
>    Affects Versions: 3.1.0
>            Reporter: Taylor Cox
>            Assignee: Taylor Cox
>            Priority: Major
>
> Dropping a table leads to undefined behavior when that table is the source of an existing materialized view. The following behavior is observed:
>  
>  * Table still appears in 'show tables' despite not being in metastore
>  * Actions on table hang and then display a "could not fetch table" error
>  * Rebuilding any dependent materialized view has same error
> It seems that the root cause is the fact that users are allowed to issue a DROP TABLE command against a table even if there is a materialized view using this table at the time. This is not something I have seen other query languages permit. 
> Repro steps: Launch these commands from any Hive 3 client:
> {code:java}
> create table footable (id int); insert into footable values (1), (2), (3);
> create materialized view mv_footable as select count(*) from footable;
> drop table footable;
> --These lines have unexpected behavior
> show tables;
> select * from footable;
> alter materialized view mv_footable rebuild;{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)