Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Drill >> mail # dev >> Next steps on the REST API

Copy link to this message
Next steps on the REST API
Hi Jacques,

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