+1.
Alan.
On Tue, Dec 19, 2017 at 8:14 AM, Peter Vary wrote:
> Hi,
>
> I did some testing. Added a new exception to the alter_function method on
> server side and used an old client with erroneous date to get this new
> exception. What I have found that a TApplicationException is thrown for the
Hi,
I did some testing. Added a new exception to the alter_function method on
server side and used an old client with erroneous date to get this new
exception. What I have found that a TApplicationException is thrown for the
user of the client, like this:
org.apache.thrift.TApplicationExceptio
Sorry, I didn’t make clear which suggestion I was responding to, as there
are multiple suggestions in the thread.
Adding new exceptions is fine, as long as it doesn’t break old clients
like Thejas mentions. And clearly cleaning up NPEs is good. Changing
which exceptions are thrown when a partic
Alan,
The changes suggested by Peter was to add another checked exception, which
is a subclass of TException. And TException is already being thrown by all
thrift api calls. So it should not break any applications.
The only concern I have is some issues if old client is used with new
servers. We ne
Hi Alan,
I think I understand your point. If we come up with the standalone MetaStore
but the interface is completely different then the original one, then we will
lose in adoption. I agree with your assessment.
Do you (or anyone) have any ideas, how can we rationalize the interface without
di
We do not want to break either the Thrift APIs or the IMetaStoreClient
ones. I do not know if we have ever declared them to be public or not, but
they are de facto public in that everyone uses them. Consider that these
are used by Impala, Presto, Qubole, Amazon's Glue, Spark, and probably
others
If the application using the old API does not handle the original exceptions
differently than the TExceptions then it should work as expected.
> On Dec 14, 2017, at 10:50 PM, Thejas Nair wrote:
>
> This direction looks good to me.
> If the new exceptions are inheriting from TException the appli
It makes perfect sense to me to clean up the API when we release the standalone
MetaStore.
+1 for the API cleanup in general!
> On Dec 15, 2017, at 1:53 AM, Alexander Kolbasov wrote:
>
> +1 for API cleanup in general!
>
> On Thu, Dec 14, 2017 at 4:25 PM, Sergey Shelukhin
> wrote:
>
>> If we
+1 for API cleanup in general!
On Thu, Dec 14, 2017 at 4:25 PM, Sergey Shelukhin
wrote:
> If we break the APIs, can we also do the API cleanup where we remove
> duplicate ones and change everything to use req/resp pattern?
>
> On 17/12/14, 13:50, "Thejas Nair" wrote:
>
> >This direction looks g
If we break the APIs, can we also do the API cleanup where we remove
duplicate ones and change everything to use req/resp pattern?
On 17/12/14, 13:50, "Thejas Nair" wrote:
>This direction looks good to me.
>If the new exceptions are inheriting from TException the applications
>would
>still work.
What is the "official status" of these APIs? Were they ever documented and
advertised as public? Or clients were always using them at their own risk?
Were there any commitment to maintain compatibility of these APIs?
Which is considered "more official" - the Thrift APIs or IMetastore ones?
Which o
What are expectations for Hive 3 in terms of API compatibility - especially
in regards to old clients talking to Hive 3 servers?
- Alex
On Thu, Dec 14, 2017 at 1:50 PM, Thejas Nair wrote:
> This direction looks good to me.
> If the new exceptions are inheriting from TException the applications
This direction looks good to me.
If the new exceptions are inheriting from TException the applications would
still work. But would it still work if we old metastore client library is
used with a newer version of metastore server running with these changes ?
On Wed, Dec 13, 2017 at 4:02 AM, Peter
Hi,
Is it acceptable to introduce backward incompatible changes in the Thrift
interface in the 3.0.0. release?
If we want to handle the validation on the server side - so every Thrift user
can benefit from the changes - then we have to add new exceptions to the throws
clause on the method decla
Hi Team,
Since the work begin to separate the HMS to a standalone project we thought
that it would be useful the create extensive API tests for the public APIs of
the new project.
We started to create tests using the IMetaStoreClient interface implementations
and found that not surprisingly the
15 matches
Mail list logo
