Hello, Ideally we should deprecate APIs in one release and remove them in a subsequent major release. If the HMS deprecations were added in Hive 3.X then I am ok removing them now. Otherwise it is not really that we will remove deprecated APIs but we will remove regular APIs without any notice.
Best, Stamatis On Thu, Jun 1, 2023 at 2:57 AM Sai Hemanth Gantasala <saihema...@cloudera.com.invalid> wrote: > > Hi everyone, > > This thread is to initiate a discussion on the removal of deprecated APIs > in the HMS thrift class. Any client including HiveMetastoreClient talks to > HiveMetaStore Server via the thrift layer. Over the past few years, the > thrift class is bloated with duplicated APIs with varying parameters > (function overloading) in the API definition. The reason why the APIs are > being deprecated is that the API might need an additional argument, so a > new API is added with an additional argument, and mark the old API as > deprecated. > > I'm working on HIVE-26537 <https://issues.apache.org/jira/browse/HIVE-26537> > to clean up the code around the interaction between HiveMetaStoreClient and > HMS to not use the deprecated APIs (the HMS client will now be using > request-based APIs instead of APIs using individual arguments). Going > forward, using these request-based APIs is ideal as we can just add an > additional field to request object definition in the thrift class and API > remains unchanged. This would hopefully require minimal changes between > client and server interaction in the future. > > I would like to hear the community member's opinions regarding the > deprecated APIs, > 1) Keep the deprecated APIs for the 4.x release, HMSClient will use the > request-based APIs, So that would keep the older clients compatible with > the new HMS server. > 2) Remove the deprecated APIs for the 4.x release. This would break > backward compatibility with the older clients but we have the opportunity > to clean up a lot of deprecated code. Since we are making a major release > after 5 years, I hope this incompatibility is acceptable. > > Please let me know your thoughts. > > Thanks, > Sai.
