You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Taylor Cox (JIRA)" <ji...@apache.org> on 2019/01/22 21:47:00 UTC
[jira] [Assigned] (HIVE-21125) Hive does not check for dependent
materialized views when issuing a DROP TABLE command
[ https://issues.apache.org/jira/browse/HIVE-21125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Taylor Cox reassigned HIVE-21125:
---------------------------------
Assignee: Taylor Cox
> 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)