[
https://issues.apache.org/jira/browse/DRILL-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Venki Korukanti updated DRILL-4729:
-----------------------------------
Description:
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.
was:
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.
> 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)
