hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasad Mujumdar <>
Subject Re: Thoughts on new metastore APIs
Date Wed, 05 Mar 2014 23:05:46 GMT
@Brock, Thanks for bring this up.


On Wed, Mar 5, 2014 at 11:39 AM, Brock Noland <> wrote:

> Hi,
> There is a ton of great work going into the 0.13 release.
> Specifically, we are adding a ton of APIs to the metastore:
> Few of these new API's follow the best practice of a single request
> and response struct. Some follow this partially by having a single
> response object but take no arguments while others return void and
> take a single request object.  Still others, mostly related to
> authorization, do not even partially follow this pattern.
> The single request/response struct model is extremely important as
> changing the number of arguments is a backwards incompatible change.
> Therefore the only way to change an api is to add *new* methods calls.
> This is why we have so many crazy APIs in the hive metastore such as
> create_table/create_table_with_environment_context and 12 (yes,
> twelve) ways to get partitions.
> I would like to suggest that we require all new APIs to follow the
> single request/response struct model. That is any new API that would
> be committed *after* today.
> I have heard the following arguments against this approach which I
> believe to be invalid:
> *This API will never change (or never return a value or never take
> another value)*
> We all have been writing code enough that we don't know, there are
> unknown unknowns. By following the single request/response struct
> model for *all* APIs we can future proof ourselves. Why wouldn't we
> want to buy insurance now when it's cheap?
> *The performance impact of wrapping an object is too much*
> These calls are being made over the network which is orders of
> magnitude slower than creating a small, simple, and lightweight object
> to wrap method arguments and response values.
> Cheers,
> Brock

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message