[
https://issues.apache.org/jira/browse/DRILL-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14180514#comment-14180514
]
Alexander Zarei commented on DRILL-1537:
----------------------------------------
Hi Parth,
I completely agree with that the querySubmitter example I added may be
misleading (by using a shared context for queries after the first query). I
just wanted to demonstrate it is possible to associate results with queries
using contexts with minimal code.
In addition, regarding "*I don't this it is OK for an application to know
about a structure that is internal to the API implementation*." Totally agreed!
That's why we suggested not to pass a *DrillClientQueryResult* pointer to the
*queryResultListener* function. Your suggestion is also quite valid and can fix
the problem. However, I have one last question:
So if I get it right you suggest:
In C++ Client pass the query handle to the result listener function:
pResultsListener(pDrillClientQueryResult, ...);
And in the result listener function pass the query handle back to C++ Client to
get the application context.
void * DrillClient::getApplicationContext(QueryHandle_t handle);
So my question is that why do we pass pDrillClientQueryResult to query result
listener when the class DrillClientQueryResult is not known to the listener
function and hence it cannot be used? Why don't we directly pass the
application context to the query result listener as in:
pResultsListener(pDrillClientQueryResult->getListenerContext(),
...);
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
> Attachments: Drill-1537-patch-1.diff
>
>
> 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 C++ Client.
> 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)
