[
https://issues.apache.org/jira/browse/DRILL-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339777#comment-15339777
]
ASF GitHub Bot commented on DRILL-4729:
---------------------------------------
GitHub user vkorukanti opened a pull request:
https://github.com/apache/drill/pull/530
DRILL-4729: Add support for prepared statement implementation on server side
+ Add following APIs for Drill Java client
- DrillRpcFuture<CreatePreparedStatementResp>
createPreparedStatement(final String query)
- void executePreparedStatement(final PreparedStatement
preparedStatement, UserResultsListener resultsListener)
- List<QueryDataBatch> executePreparedStatement(final PreparedStatement
preparedStatement) (for testing purpose)
+ Separated out the interface from UserClientConnection. It makes it easy
to have wrappers which need to
tap the messages and data going to the actual client.
+ Implement CREATE_PREPARED_STATEMENT and handle RunQuery with
PreparedStatement
+ Test changes to support prepared statement as query type
+ Add tests in TestPreparedStatementProvider
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/vkorukanti/drill DRILL-4729
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/drill/pull/530.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #530
----
commit 32ba03c7abd9a3784c9a5376dd2835325fe8d5f9
Author: vkorukanti <[email protected]>
Date: 2016-06-09T23:03:06Z
DRILL-4728: Add support for new metadata fetch APIs
+ Protobuf messages
- GetCatalogsReq -> GetCatalogsResp
- GetSchemasReq -> GetSchemasResp
- GetTablesReq -> GetTablesResp
- GetColumnsReq -> GetColumnsResp
+ Java Drill client changes
+ Server side changes to handle the metadata API calls
- Provide a self contained `Runnable` implementation for each metadata API
that process the requests and sends the response to client
- In `UserWorker` override the `handle` method that takes the
`ResponseSender` and
send the response from the `handle` method instead of returning it.
- Add a method for each new API to UserWorker to submit the metadata work.
- Add a method `addNewWork(Runnable runnable)` to `WorkerBee` to submit a
generic
`Runnable` to `ExecutorService`.
- Move out couple of methods from `QueryContext` into a separate interface
`SchemaConfigInfoProvider` to enable instantiating Schema trees without
the
full `QueryContext`
+ New protobuf messages increased the `jdbc-all.jar` size. Up the limit to
21MB.
Change-Id: I5a5e4b453caf912d832ff8547c5789c884195cc4
commit c520eda8a2169e173763e5f84d919c87de46e895
Author: vkorukanti <[email protected]>
Date: 2016-06-13T18:20:25Z
DRILL-4729: Add support for prepared statement implementation on server side
+ Add following APIs for Drill Java client
- DrillRpcFuture<CreatePreparedStatementResp>
createPreparedStatement(final String query)
- void executePreparedStatement(final PreparedStatement
preparedStatement, UserResultsListener resultsListener)
- List<QueryDataBatch> executePreparedStatement(final PreparedStatement
preparedStatement) (for testing purpose)
+ Separated out the interface from UserClientConnection. It makes it easy
to have wrappers which need to
tap the messages and data going to the actual client.
+ Implement CREATE_PREPARED_STATEMENT and handle RunQuery with
PreparedStatement
+ Test changes to support prepared statement as query type
+ Add tests in TestPreparedStatementProvider
Change-Id: Id26cbb9ed809f0ab3c7530e6a5d8314d2e868b86
----
> Add support for prepared statement implementation on server side
> ----------------------------------------------------------------
>
> Key: DRILL-4729
> URL: https://issues.apache.org/jira/browse/DRILL-4729
> Project: Apache Drill
> Issue Type: Sub-task
> Components: Metadata
> Reporter: Venki Korukanti
> Assignee: Venki Korukanti
> Fix For: 1.8.0
>
>
> Currently Drill JDBC/ODBC driver implements its own prepared statement
> implementation, which basically issues limit 0 query to get the metadata and
> then executes the actual query. So the query is planned twice (for metadata
> fetch and actual execution). Proposal is to move that logic to server where
> we can make optimizations without disrupting/updating the JDBC/ODBC drivers.
> * {{PreparedStatement createPreparedStatement(String query)}}.
> {{PreparedStatement}} object contains the following:
> ** {{ResultSetMetadata getResultSetMetadata()}}
> *** {{ResultsSetMetadata}} contains methods to fetch info about output
> columns of the query. What info these methods provide is given in this
> [spreadsheet|https://docs.google.com/spreadsheets/d/1A6nqUQo5xJaZDQlDTittpVrK7t4Kylycs3P32Yn_O5k/edit?usp=sharing].
> It lists the ODBC/JDBC requirements and what Drill will provided through
> object {{ResultsSetMetadata}}.
> *** Server can put more info here which is opaque to client and use it in
> server when the client sends execute prepared statement query request.
> Overload the current submit query API to take the {{PreparedStatement}}
> returned above.
> In the initial implementation, server side implementation of
> {{createPreparedStatement}} API is implemented as follows:
> * Runs the query with {{LIMIT 0}}, gets the schema
> * Convert the query into a binary blob and set it as opaque object in
> {{PreparedStatement}}.
> When the {{PreparedStatement}} is submitted for execution, reconstruct the
> query from binary blob in opaque component of {{PreparedStatement}} and
> execute it from scratch.
> Opaque component of the {{PreparedStatement}} is where we can save more
> information which we can use for optimizations/speedups.
> NOTE: We are not going to worry about parameters in prepared query in initial
> implementation. We can provide the functionality later if there is sufficient
> demand from Drill community.
> Changes in this patch are going to include protobuf messages, server side
> messages and Java client APIs. Native client changes are going to be tracked
> in a separate JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
