Zhihua brought up a good point. Yes if it was introduced in 4.0.0-alpha and then was deprecated we can remove it.
On Thu, Jun 1, 2023 at 1:00 PM Attila Turoczy <aturo...@cloudera.com.invalid> wrote: > > +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. > >
