Any thoughts on this?
---------- Forwarded message ----------
From: Srihari Srinivasan <[EMAIL PROTECTED]>
Date: Wed, Aug 7, 2013 at 6:30 PM
Subject: Next steps on the REST API
To: [EMAIL PROTECTED]
Summarizing a couple of questions and changes needed.
- Is there any overhead to instantiating a new DrillClient, connecting
to a drillbit and closing the connection per http request? Jersey creates a
new instance of the Resource class for each request and the DrillClient
will get instantiated per request unless we make it a static variable.
- I am assuming that the DrillClient which will be instantiated from the
http layer will always connect to the co-located/localhost Drillbit
With respect to the DrillClient we'll need the following methods to support
the async style interaction. If we agree to supporting this design I'll
create a JIRA for this -
- new DrillClient().submitQuery(QueryType, Query String) that returns
the *QueryId* *and continues to execute in the background*
- new DrillClient().getStatus(queryId) that returns a Status object. It
could just return *IN_PROGRESS, SUCCEEDED and FAILED* for now. And some
way to know why it failed in case it did.
- new DrillClient().getResults(queryId) that returns
*QueryResultBatch*as it is doing now.
While the api I've speced out above is the ideal one I guess this will
require more time and effort to implement it as suggested. Especially for
the getStatus and getResults methods as it implies that the state of a
query's lifecycle will be held/persisted by someone. Is the server already
maintaining some state for tracking the lifecycle of a query which can be