+1 from me as well. Let's clean it up. Still, because we have struggled with the data correctness issue, we have time to introduce these changes. If won't fit then won't be a problem as well, as the next release will contain it. As I wrote earlier, as the 4.0 goes out I want to help to have regular releases. Even majors. I have started a proposal document about a public hive roadmap, and release roadmap that I want to share and discuss with the community.
-Attila On Thu, Jun 1, 2023 at 12:37 PM dengzhhu653 <dengzhhu...@163.com> wrote: > 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. >
