[
https://issues.apache.org/jira/browse/DRILL-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Zarei updated DRILL-1537:
-----------------------------------
Description:
When submitting queries by the function *SubmitQuery(QueryType t, string& plan,
pfnQueryResultsListener l, void\* lCtx)* of drillClientImp class, the
listenerContext parameter provides a convenient way of associating returned
results with submitted queries.
The way it works is that the calling application passes the context to
*SubmitQuery* and when returning results, *processQueryResult* passes the
context to the *queryResultListener* callback function. As such, the callback
function can associate the returned result with the context.
When we were updating QuerySubmitter example to showcase usage of *SubmitQuery*
with context, we noticed *processQueryResult* function does not pass the
context directly to the *queryResultListener* callback function; Instead, an
instance of DrillClientQueryResult which contains the context as a data member
is passed to the *queryResultListener*. This requires the *queryResultListener*
function, which is implemented in consumers of the C++ Client, to know about
the DrillClientQueryResult.
However, DrillClientQueryResult is not in the public API of the DrillClient.
Two solutions are imaginable at the first glance: First, passing the context
instead of a DrillClientQueryResult, which we implemented and tested it;
Second, moving DrillClientQueryResult to the public API; Moving
DrillClientQueryResult to the public API does not seem to be desirable as it is
internal detail for the C++ Client.
I was wondering what your thoughts are on this.
Thanks,
Alex
was:
When submitting queries by the function *SubmitQuery(QueryType t, string& plan,
pfnQueryResultsListener l, void* lCtx)* of drillClientImp class, the
listenerContext parameter provides a convenient way of associating returned
results with submitted queries.
The way it works is that the calling application passes the context to
*SubmitQuery* and when returning results, *processQueryResult* passes the
context to the *queryResultListener* callback function. As such, the callback
function can associate the returned result with the context.
When we were updating QuerySubmitter example to showcase usage of *SubmitQuery*
with context, we noticed *processQueryResult* function does not pass the
context directly to the *queryResultListener* callback function; Instead, an
instance of DrillClientQueryResult which contains the context as a data member
is passed to the *queryResultListener*. This requires the *queryResultListener*
function, which is implemented in consumers of the C++ Client, to know about
the DrillClientQueryResult.
However, DrillClientQueryResult is not in the public API of the DrillClient.
Two solutions are imaginable at the first glance: First, passing the context
instead of a DrillClientQueryResult, which we implemented and tested it;
Second, moving DrillClientQueryResult to the public API; Moving
DrillClientQueryResult to the public API does not seem to be desirable as it is
internal detail for the C++ Client.
I was wondering what your thoughts are on this.
Thanks,
Alex
> C++ Client: Passing the listener context to queryResultListener function
> ------------------------------------------------------------------------
>
> Key: DRILL-1537
> URL: https://issues.apache.org/jira/browse/DRILL-1537
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - ODBC
> Reporter: Alexander Zarei
>
> When submitting queries by the function *SubmitQuery(QueryType t, string&
> plan, pfnQueryResultsListener l, void\* lCtx)* of drillClientImp class, the
> listenerContext parameter provides a convenient way of associating returned
> results with submitted queries.
> The way it works is that the calling application passes the context to
> *SubmitQuery* and when returning results, *processQueryResult* passes the
> context to the *queryResultListener* callback function. As such, the callback
> function can associate the returned result with the context.
> When we were updating QuerySubmitter example to showcase usage of
> *SubmitQuery* with context, we noticed *processQueryResult* function does not
> pass the context directly to the *queryResultListener* callback function;
> Instead, an instance of DrillClientQueryResult which contains the context as
> a data member is passed to the *queryResultListener*. This requires the
> *queryResultListener* function, which is implemented in consumers of the C++
> Client, to know about the DrillClientQueryResult.
> However, DrillClientQueryResult is not in the public API of the DrillClient.
> Two solutions are imaginable at the first glance: First, passing the context
> instead of a DrillClientQueryResult, which we implemented and tested it;
> Second, moving DrillClientQueryResult to the public API; Moving
> DrillClientQueryResult to the public API does not seem to be desirable as it
> is internal detail for the C++ Client.
> I was wondering what your thoughts are on this.
> Thanks,
> Alex
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
