+1 @Brock, Thanks for bring this up. thanks Prasad
On Wed, Mar 5, 2014 at 11:39 AM, Brock Noland <br...@cloudera.com> 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: > > > https://github.com/apache/hive/blame/trunk/metastore/if/hive_metastore.thrift > > 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 >
