jdbc: metadata: support prepared statements #249
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nicktorwald
force-pushed
the
nicktorwald/gh-198-server-prepared-statement
branch
from
c42ebdc to
db21a6a
Compare
|
At this moment the driver can obtain parameter info ( |
The driver can connect to different Tarantool instances within a range of server versions. Sometimes, it's required to set a driver behaviour depending on those versions (i.e. in scope of #213 the driver needs to generate the functions for JDBC C4 LTRIM/RTRIM that are recognizable by a particular Tarantool version). This commit also includes implementation of two public DatabaseMetaData methods getDatabaseMajorVersion and getDatabaseMinorVersion. Affects: #213 Closes: #106
Tarantool introduced a new PREPARE protocol operation to be able to create a prepared statement on the server side. This can be used by JDBC SQLPreparedStatement implementation that will prepare its query in advance to get meta data as well as reuse it multiple times. These JDBC features will be introduced in future commits. This commit add all the required protocol constants and allow TarantoolClient to abstract from concrete operation codes related to SQL. Because the native client does not provide API to perform PREPARE it does not handle it in completeSql() as a completely unexpected operation here. Follows on: #198
nicktorwald
force-pushed
the
nicktorwald/gh-198-server-prepared-statement
branch
from
db21a6a to
86b3c43
Compare
nicktorwald
changed the title
Tarantool supports prepared statements since 2.3.1 that can be used by java.sql.PreparedStatement to prepare the underlying query in advance. If the driver connects to Tarantool which supports the prepared statements then each PreparedStatement object acts as a corresponding server prepared statement in terms of its behaviour (including expiration or invalidation of statements - i.e. after DDL operations). It also makes possible to obtain statement meta data via getMetaData and getParameterMetaData without having to execute the query. This commit extends TarantoolConnection API by new `prepare` and `deallocate` methods that allow to deal with server prepared statements. It caused a small reworking of a query execution process in SQLConnection where QueryCommand abstraction was introduced. Another extension is support of PreparedStatement that works in two different modes now: legacy mode when server prepared statements are not available (driver will send sql text + parameters as a separate queries when each execution is performed) and new mode when they are supported (each PreparedStatement covers the server prepared statement and sends statement id + parameters). There are a few issues on using the prepared statement now. The first, it is required to deallocate prepared statements explicitly, (no an eviction strategy on the server side) so PreparedStatement tries to perform it when close() method is called. It causes the second issue. The second, Tarantool does not distinguish query duplicates within one session that can cause unexpected user experience. Let's say there are two PreparedStatements that were prepared using the same query string. If one of them closes it makes another statement broken because of they reused the same session prepared statement. To overcome this issue the driver connection tracks its own statements references. When the particular statement reference count reaches zero it will safely unprepared it on the server side. The third, the prepared statement is invalidated by DDL queries or the disconnection. Tarantool does not support auto re-preparing after DDL operation at this moment, so it requires to be re-prepared for all cached statements. Here, the PreparedStatement repeats behaviour of Lua implementation for `box` module - returns an error when it expired or deleted. Closes: #198
In addition to result set metadata it's possible to examine parameters of PreparedStatement using getParameterMetaData() method. Because Tarantool returns extra info related to query parameters as a result of PREPARE operation, we can fill ParameterMetaData by available info. However, the server sends always 'ANY' as a target parameter type for parameters and the driver treats all of them as UNKNOWN type. Once the server starts to send proper types (such as integer, string and so on) the driver should parse it automatically (required to be tested in future). Follows on: #173
nicktorwald
force-pushed
the
nicktorwald/gh-198-server-prepared-statement
branch
from
86b3c43 to
a404c8d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Affects: #213
Closes: #106
Closes: #198
Follows on: #173