[
https://issues.apache.org/jira/browse/DRILL-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14180834#comment-14180834
]
Parth Chandra commented on DRILL-1537:
--------------------------------------
I think the confusion is really because of the confusing names.
We have two identifiers 1) a query handle and 2) an application context.
The following flow occurs -
1) Application creates an application context.
2) Application submits a query with the application context as input. The
client lib returns a query handle.
Now the contract that the API has with the application is
a) The query handle is guaranteed to be able to identify the query uniquely.
b) The application can ask for results of any current query by using the
query handle.
c) The query handle is just an identifier. The fact that it is a pointer to
an object is not part of the contract. That is why it is of type queryHandle_t.
queryHandle_t is a void* but it could just as easily have been a uint64_t or a
UUID. The implementation could have used a UUID to look up an internal map and
got the corresponding query results from the map for instance.
d) The API guarantees that it will not look at the application context but
will keep a map between the query handle and application context and will give
it back to the application when there are results available.
Now it would have been nicer if the callback signature was such that the
application context _and_ the query handle were returned to the application.
But we don't do that, and, because the idea of an application context was
pushed in as an after thought, we did not provide a way to get it back either.
The API I outlined above is simple enough to use and implement that we
really should just implement it. And it should take care of your requirement.
HTH
> 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)
