Reg: Discussion on removal of deprecated APIs in the HMS thrift interface

[Sai Hemanth Gantasala <sa...@cloudera.com.INVALID>]

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.

Re: Re: Reg: Discussion on removal of deprecated APIs in the HMS thrift interface

[Sai Hemanth Gantasala <sa...@cloudera.com.INVALID>]

Hi all,

Thanks for the constructive feedback and I'm happy that the community
agreed on one opinion.
I'll go ahead with the consensus view. Thanks again for taking the time to
provide valuable feedback.

Thanks,
Sai.

On Wed, Jun 7, 2023 at 10:03 PM vihang karajgaonkar <vi...@apache.org>
wrote:

> +1 on removing unreleased and deprecated APIs. For the APIs which have been
> released, we should mark them deprecated first and remove them only in the
> next major release. As many of you know, Hive metastore APIs are used by
> many other systems outside Hive too and we should be careful not make
> breaking changes without giving reasonable notice.
>
> On Thu, Jun 1, 2023 at 4:29 AM Stamatis Zampetakis <za...@gmail.com>
> wrote:
>
> > 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
> > <at...@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 <de...@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" <ay...@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 <
> zabetak@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
> > > > >>> <sa...@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.
> > > >
> >
>

Re: Re: Reg: Discussion on removal of deprecated APIs in the HMS thrift interface

[vihang karajgaonkar <vi...@apache.org>]

+1 on removing unreleased and deprecated APIs. For the APIs which have been
released, we should mark them deprecated first and remove them only in the
next major release. As many of you know, Hive metastore APIs are used by
many other systems outside Hive too and we should be careful not make
breaking changes without giving reasonable notice.

On Thu, Jun 1, 2023 at 4:29 AM Stamatis Zampetakis <za...@gmail.com>
wrote:

> 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
> <at...@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 <de...@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" <ay...@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 <za...@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
> > > >>> <sa...@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.
> > >
>

Re: Re: Reg: Discussion on removal of deprecated APIs in the HMS thrift interface

[Stamatis Zampetakis <za...@gmail.com>]

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
<at...@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 <de...@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" <ay...@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 <za...@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
> > >>> <sa...@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.
> >

Re: Re: Reg: Discussion on removal of deprecated APIs in the HMS thrift interface

[Attila Turoczy <at...@cloudera.com.INVALID>]

+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 <de...@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" <ay...@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 <za...@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
> >>> <sa...@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.
>

Re:Re: Reg: Discussion on removal of deprecated APIs in the HMS thrift interface

[dengzhhu653 <de...@163.com>]

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" <ay...@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 <za...@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
>>> <sa...@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.

Re: Reg: Discussion on removal of deprecated APIs in the HMS thrift interface

[Ayush Saxena <ay...@gmail.com>]

+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 <za...@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
>> <sa...@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.

Re: Reg: Discussion on removal of deprecated APIs in the HMS thrift interface

[Stamatis Zampetakis <za...@gmail.com>]

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
<sa...@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.