[
https://issues.apache.org/jira/browse/HIVE-21125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taylor Cox updated HIVE-21125:
------------------------------
Description:
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}
was:
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}
> 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
> 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)
