Thanks for the detailed explanation.
If we follow a consistent pattern of creating a new Request/Response
object for each method, I think the readability is not hurt by this
approach.
I think the best practice can be clarified as "practice of a single
request and response struct, specific for each
On Thu, Mar 6, 2014 at 12:13 PM, Thejas Nair wrote:
> Thanks for discussing this, Brock. I agree that is important to
> consider while writing a new metastore api call.
> But I think this (single input/output struct) should be a guideline,
> I am not sure if this should be used in every case.
As
Thanks for discussing this, Brock. I agree that is important to
consider while writing a new metastore api call.
But I think this (single input/output struct) should be a guideline,
I am not sure if this should be used in every case.
What you are saying shows that there is a tradeoff between endi
+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 wrote:
> +1
> @Brock, Thanks for bring this up.
>
> thanks
> Prasad
>
>
>
> On Wed, Mar 5, 2014 at 11:39 AM, Brock Noland wrote:
>
> > Hi,
> >
> >
> > There is
+1
@Brock, Thanks for bring this up.
thanks
Prasad
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:
>
>
> https://github.com/apache/hive/blame/trunk/metast
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 f
