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
