Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Content-Type: multipart/alternative;
 boundary="===============8411832896211506095=="
MIME-Version: 1.0
Subject: Re: Review Request 56118: DROP TABLE in hive doesn't Throw Error
From: Aihua Xu <axu@cloudera.com>
To: Peter Vary <pvary@cloudera.com>, Sergio Pena <sergio.pena@cloudera.com>,
 Aihua Xu <axu@cloudera.com>
Cc: hive <dev@hive.apache.org>, Adam Szita <szita@cloudera.com>
Date: Fri, 10 Feb 2017 14:54:05 -0000
Message-ID: <20170210145405.31773.18156@reviews.apache.org>
Auto-Submitted: auto-generated
Sender: Aihua Xu <noreply@reviews.apache.org>
References: <20170203142249.1722.87128@reviews.apache.org>
In-Reply-To: <20170203142249.1722.87128@reviews.apache.org>
Reply-To: Aihua Xu <axu@cloudera.com>
archived-at: Fri, 10 Feb 2017 14:54:08 -0000

--===============8411832896211506095==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/56118/#review165125
-----------------------------------------------------------


metastore/src/java/org/apache/hadoop/hive/metastore/HiveMetaStore.java (line 1679)
<https://reviews.apache.org/r/56118/#comment236939>

    Actually it still has the issue here. 
    
    With this change, if the data deletion fails, now Hive will roll back the metastore DB change, but the actual data may not be recovered. That will still put the table in inconsistent state. 
    
    I guess this part doesn't need change. But even that, it will cause issue since if we return deleting fails, from the user point of view, the table should be intact but actually it's already deleted.
    
    So I'm rethinking of this jira. Maybe we have to keep like this, since the current behaivor seems to be the best with those nonatomic operations. 
    
    For hive, if metastore info is removed, then it's considered table deleted. For external table, actually the data would not get removed.


metastore/src/java/org/apache/hadoop/hive/metastore/HiveMetaStore.java (line 1811)
<https://reviews.apache.org/r/56118/#comment236940>

    Now when we throw the exception here, if there is one partition we can't delete, it will stop rather than continuing deleting the remaining. 
    
    I would suggest not to throw exception but return a true/false flag to indicate deletion success or failure. Same for deleteTableData.


- Aihua Xu


On Feb. 3, 2017, 2:22 p.m., Adam Szita wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56118/
> -----------------------------------------------------------
> 
> (Updated Feb. 3, 2017, 2:22 p.m.)
> 
> 
> Review request for hive, Aihua Xu, Peter Vary, and Sergio Pena.
> 
> 
> Bugs: HIVE-14181
>     https://issues.apache.org/jira/browse/HIVE-14181
> 
> 
> Repository: hive-git
> 
> 
> Description
> -------
> 
> Failure during table drop doesn't throw errors and results in success - some times data resides in warehouse, but table (meta data) is removed from metastore resulting in incosistency
> 
> 
> Diffs
> -----
> 
>   common/src/java/org/apache/hadoop/hive/conf/HiveConf.java 53b9b0c6962c9b1cd2eef1cb71687ec0245cfac3 
>   itests/hive-unit/src/test/java/org/apache/hadoop/hive/metastore/TestHiveMetaStore.java af125c38236582ba532f5e3de3d2ba724f38b101 
>   metastore/src/java/org/apache/hadoop/hive/metastore/HiveMetaStore.java f8c3c4e48db0df9d6c18801bcd61f9e5dc6eb7c2 
> 
> Diff: https://reviews.apache.org/r/56118/diff/
> 
> 
> Testing
> -------
> 
> -Added test case
> -Tested on cluster
> 
> 
> Thanks,
> 
> Adam Szita
> 
>


--===============8411832896211506095==--