You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "John Sherman (Jira)" <ji...@apache.org> on 2023/04/26 00:04:00 UTC

[jira] [Comment Edited] (HIVE-27298) Provide implementation of HMS thrift service that throws UnsupportedOperationException

    [ https://issues.apache.org/jira/browse/HIVE-27298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716473#comment-17716473 ] 

John Sherman edited comment on HIVE-27298 at 4/26/23 12:03 AM:
---------------------------------------------------------------

I'm inclined to go with:
a) since AbstractThriftHiveMetastore provides no value otherwise (users should be implementing against ThriftHiveMetastore.Iface for similar guarantees that AbstractThriftHiveMetastore today provides). The class name may be confusing, but I also do not associate a class having Abstract in the name as being an abstract class (others might though).

However, b has the advantage that it doesn't change the behavior that downstream implementations may rely on (even if I think it is pointless). Though, I work on one of the downstream implementations (IMPALA) and AbstractThriftHiveMetastore was added to support our use case. I think Impala is the only user of this class but I can't prove that.

This comment from AbstractThriftHiveMetastore illustrates the intent that the current implementation actually does not provide:
{code}
/**
 * This abstract class can be extended by any remote cache that implements HMS APIs.
 * The idea behind introducing this abstract class is not to break the build of remote cache,
 * whenever we add new HMS APIs.
 */
{code}


was (Author: jfs):
I'm inclined to go with:
a) since AbstractThriftHiveMetastore provides no value otherwise (users should be implementing against ThriftHiveMetastore.Iface for similar guarantees that AbstractThriftHiveMetastore today provides). The class name may be confusing, but I also do not associate a class having Abstract in the name as being an abstract class (others might though).

However, b has the advantage that it doesn't change the behavior that downstream implementations may rely on (even if I think it is pointless). Though, I work on one of the downstream implementations (IMPALA) and AbstractThriftHiveMetastore was added to support our use case. I think Impala is the only user of this class but I can't prove that.

> Provide implementation of HMS thrift service that throws UnsupportedOperationException
> --------------------------------------------------------------------------------------
>
>                 Key: HIVE-27298
>                 URL: https://issues.apache.org/jira/browse/HIVE-27298
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: John Sherman
>            Priority: Major
>
> The intent of HIVE-25005 and AbstractThriftHiveMetastore class was to provide default implementation for every HMS thrift method that throws UnsupportedOperationException.
> However - HIVE-25005 made the class abstract, so as a result there are a variety of HMS service methods that are not implemented in AbstractThriftHiveMetastore.
> We should either:
> a) remove abstract from the class definition AbstractThriftHiveMetastore
> or
> b) add a new class that is not abstract.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)