+1. It would be nice to deprecate some "classic" APIs superseded by req/resp APIs too
On Wed, Mar 5, 2014 at 3:05 PM, Prasad Mujumdar <pras...@cloudera.com>wrote: > +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 > > > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
