[ 
https://issues.apache.org/jira/browse/HIVE-25282?focusedWorklogId=620633&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-620633
 ]

ASF GitHub Bot logged work on HIVE-25282:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 08/Jul/21 17:48
            Start Date: 08/Jul/21 17:48
    Worklog Time Spent: 10m 
      Work Description: nrg4878 commented on a change in pull request #2450:
URL: https://github.com/apache/hive/pull/2450#discussion_r666401686



##########
File path: 
standalone-metastore/metastore-server/src/main/java/org/apache/hadoop/hive/metastore/HMSHandler.java
##########
@@ -5934,6 +5936,12 @@ private void alter_table_core(String catName, String 
dbname, String name, Table
       catName = MetaStoreUtils.getDefaultCatalog(conf);
     }
 
+    // HIVE-25282: Drop/Alter table in REMOTE db should fail
+    Database db = get_database_core(catName, dbname);

Review comment:
       per the comment above, can you wrap this code in a try/catch and 
re-throw the NoSuchObjectException as an InvalidOperationException? Ideally 
this should throw back a NoSuchObjectException, but I am concerned about 
backward compatibilty with older clients.

##########
File path: 
standalone-metastore/metastore-server/src/main/java/org/apache/hadoop/hive/metastore/HMSHandler.java
##########
@@ -5882,7 +5884,7 @@ public String getVersion() throws TException {
   @Override
   public void alter_table(final String dbname, final String name,
                           final Table newTable)
-      throws InvalidOperationException, MetaException {
+      throws InvalidOperationException, MetaException, NoSuchObjectException {

Review comment:
       so I am assuming the get_database_core() call now throws a 
NoSuchObjectException that we now have to account for.
   I realize the current code is a bit inconsistent when it comes to exception 
handling. so for drop_table(), if the table does not exist, we throw a 
NoSuchObjectException. But for alter_table() if the table does not exist, we 
catch the NoSuchObjectException and rethrow it as an InvalidOperationException. 
   Ideally they should be consistent.
   
   But I am a bit concerned about throwing a new exception from HMS. It might 
be backwards-incompatible with the current code. Could you instead catch this 
and re-throw as InvalidOperationException as well. 
   

##########
File path: 
standalone-metastore/metastore-server/src/main/java/org/apache/hadoop/hive/metastore/HMSHandler.java
##########
@@ -5892,7 +5894,7 @@ public void alter_table(final String dbname, final String 
name,
   @Override
   public void alter_table_with_cascade(final String dbname, final String name,
                                        final Table newTable, final boolean 
cascade)
-      throws InvalidOperationException, MetaException {
+      throws InvalidOperationException, MetaException, NoSuchObjectException {
     EnvironmentContext envContext = null;

Review comment:
       same as above comment




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@hive.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 620633)
    Time Spent: 20m  (was: 10m)

> Drop/Alter table in REMOTE db should fail
> -----------------------------------------
>
>                 Key: HIVE-25282
>                 URL: https://issues.apache.org/jira/browse/HIVE-25282
>             Project: Hive
>          Issue Type: Sub-task
>            Reporter: Dantong Dong
>            Assignee: Dantong Dong
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 4.0.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Drop/Alter table statement should be explicitly rejected in REMOTE database. 
> In consistency with HIVE-24425: Create table in REMOTE db should fail.



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

Reply via email to