jdbc: NPE when with libreoffice base tool #198

Totktonada · 2019-06-04T16:07:06Z

I have added Tools → Options → LibreOffice → Advanced → Class Path... → /path/to/connector-1.9.3-SNAPSHOT.jar

Then I open LibreOffice Base tool and create a connection via JDBC (jdbc:tarantool://localhost:3301, JDBC driver class org.tarantool.jdbc.SQLDriver). 'Test connection' succeeds. After that I don't see my tables in 'Tables' tab. Also I tried to perform simple select * from "s" request and got 'the data content could not be loaded'.

Once I get the following error in a console (from which I run libreoffice):

java.lang.NullPointerException
  at org.tarantool.jdbc.SQLPreparedStatement.getMetaData(SQLPreparedStatement.java:316)

But now I'm not sure how to reproduce it.

The text was updated successfully, but these errors were encountered:

Totktonada · 2019-06-04T17:16:37Z

Reproduced now. It seems that I was unable to reproduce, because the connector package was contain my attempts to workaround the issue. The exception is shown after the query above created with 'Create Query in SQL View...' under 'Queries' tab.

Implement several ResultSetMetaData methods to be able be run as a proper JDBC-driver inside Base tool. Reworked SQL data types in relation with Tarantool NoSQL types as well as JDBC types. A data conversations are left out of this commit. This issue also addresses to tarantool/tarantool#3292 to be executed in a dry-run mode. LibreOffice Base uses PreparedStatement.getMetadata() without a real query execution to extract a metadata in advance. This causes NPE in #198. Follows on: #198

Tarantool introduced a new PREPARE protocol operation to be able to prepare and cache a SQL statement on the server side. It also returns metadata of the prepared statement that can be used to perform a query in dry-run mode as well as to examine IN parameters (?-bindings). It is useful for JDBC connector part where there is PreparedStatement's method getMetaData() and getParameterMetaData(). 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

Now, client is capable to perform PREPARE statements in order to obtain metadata without a real query materialization required by JDBC prepared statement. This commit extends TarantoolConnection API by new `prepare` method that allows to get prepared statement metadata in advance. It caused a small reworking of a query execution process in SQLConnection where QueryCommand abstraction was introduced. Finally, using API mentioned above, JDBC PreparedStatement fetches the prepared metadata if none of executed result sets is available. Closes: #198

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

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 support prepared the statements each PreparedStatement object acts as a corresponding server prepared statement in terms of its behaviour (including expiration or invalidation of statements - i.e. after DML 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 works in two different modes: legacy mode when 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 (each PreparedStatement covers the server prepared statement and sends statement id + parameters). There are a few issues when 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() is called. It causes next 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 on the server side. The third, the prepared statement is invalidated by DDL queries or the disconnection. Here, the PreparedStatement repeats behaviour of structure implemented in LUA (box.prepare()) - return an error when it runs. Tarantool does not support auto re-preparing after DDL operation at this moment. Closes: #198

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

Totktonada added the bug Something isn't working label Jun 4, 2019

Totktonada assigned nicktorwald Jun 17, 2019

nicktorwald mentioned this issue Jun 27, 2019

LibreOfficeBase ResultSet metadata issues #202

Merged

coveralls mentioned this issue Dec 1, 2019

jdbc: metadata: support prepared statements #249

Closed

Totktonada added this to the JDBC MVP milestone Apr 27, 2020

Totktonada mentioned this issue Jul 27, 2020

Is there a way to connect to tarantool via dbeaver tarantool/tarantool#5189

Closed

Totktonada mentioned this issue Jun 28, 2022

sql: support prepared statements tarantool/go-tarantool#180

Merged

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

jdbc: NPE when with libreoffice base tool #198

jdbc: NPE when with libreoffice base tool #198

Totktonada commented Jun 4, 2019 •

edited

Loading

Totktonada commented Jun 4, 2019

jdbc: NPE when with libreoffice base tool #198

jdbc: NPE when with libreoffice base tool #198

Comments

Totktonada commented Jun 4, 2019 • edited Loading

Totktonada commented Jun 4, 2019

Totktonada commented Jun 4, 2019 •

edited

Loading