Hi
Thanks Sai for driving this, the request based API makes sense to me. For the removal of deprecated API: a) +1 if it is marked as deprecated in 3.x; b) If the API is introduced after 4.0.0-alpha, but tend to become obsolete in 4.x GA, I think we can remove it as well. Thanks, Zhihua. At 2023-06-01 17:56:03, "Ayush Saxena" <ayush...@gmail.com> wrote: >+1 to what Stamatis said, if it is there in 3.X we can explore their removal, >else let them go in 4.x GA release and we can remove then in the subsequent >release > >-Ayush > >> On 01-Jun-2023, at 3:08 PM, Stamatis Zampetakis <zabe...@gmail.com> wrote: >> >> 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.
