jdbc: Support resultSetHoldability parameter in Connection methods #87
Comments
nicktorwald
added a commit
that referenced
this issue
Mar 19, 2019
nicktorwald
added a commit
that referenced
this issue
Mar 19, 2019
…esultset-holdability # Conflicts: # src/main/java/org/tarantool/JDBCBridge.java
nicktorwald
pushed a commit
that referenced
this issue
Mar 19, 2019
Right now we only can support HOLD_CURSORS_OVER_COMMIT due to lack of Tarantool transaction support and, possibly, cursors. So, in terms of HOLD_CURSORS_OVER_COMMIT we always load a result set completely and it can be used as long as it is opened. Implement the holdability support (next HS) for SQLDatabaseMetaData in part of getting a default holdability and checking proper support. Implement HS for SQLConnection in part of producing new statements and prepared statements (but excluding CallableStatements due to lack of implementation). Implement HS for SQL(Prepared)Statement as well as for SQLResultSet which is produced by the statements. Some part of this feature requires the implementation of java.sql.Wrapper for SQLConnection and SQL(Prepared)Statement. So now they fully implement the interface. Add missed checks for an open status of JDBC components which are required by the specification. Some methods start returning appropriate SQLException subclasses when corresponding errors occur. Add SQLStates enumeration to help to produce the errors with the standard SQL states. Finally, JDBCBridge is no longer aware of the SQLResultSet class. Only Statement implementations are responsible for building of new result sets according to the specification design. Next plan is to completely avoid JDBCBridge logic and transfer it to an inner helper inside the Statement implementations. Closes: #87 Affects: #73, #199
nicktorwald
pushed a commit
that referenced
this issue
Mar 19, 2019
Right now we only can support HOLD_CURSORS_OVER_COMMIT due to lack of Tarantool transaction support and, possibly, cursors. So, in terms of HOLD_CURSORS_OVER_COMMIT we always load a result set completely and it can be used as long as it is opened. Implement the holdability support (next HS) for SQLDatabaseMetaData in part of getting a default holdability and checking proper support. Implement HS for SQLConnection in part of producing new statements and prepared statements (but excluding CallableStatements due to lack of implementation). Implement HS for SQL(Prepared)Statement as well as for SQLResultSet which is produced by the statements. Some part of this feature requires the implementation of java.sql.Wrapper for SQLConnection and SQL(Prepared)Statement. So now they fully implement the interface. Add missed checks for an open status of JDBC components which are required by the specification. Some methods start returning appropriate SQLException subclasses when corresponding errors occur. Add SQLStates enumeration to help to produce the errors with the standard SQL states. Finally, JDBCBridge is no longer aware of the SQLResultSet class. Only Statement implementations are responsible for building of new result sets according to the specification design. Next plan is to completely avoid JDBCBridge logic and transfer it to an inner helper inside the Statement implementations. Closes: #87 Affects: #73, #119
Totktonada
pushed a commit
that referenced
this issue
Mar 21, 2019
Right now we only can support HOLD_CURSORS_OVER_COMMIT due to lack of Tarantool transaction support and, possibly, cursors. So, in terms of HOLD_CURSORS_OVER_COMMIT we always load a result set completely and it can be used as long as it is opened. Implement the holdability support (next HS) for SQLDatabaseMetaData in part of getting a default holdability and checking proper support. Implement HS for SQLConnection in part of producing new statements and prepared statements (but excluding CallableStatements due to lack of implementation). Implement HS for SQL(Prepared)Statement as well as for SQLResultSet which is produced by the statements. Some part of this feature requires the implementation of java.sql.Wrapper for SQLConnection and SQL(Prepared)Statement. So now they fully implement the interface. Add missed checks for an open status of JDBC components which are required by the specification. Some methods start returning appropriate SQLException subclasses when corresponding errors occur. Add SQLStates enumeration to help to produce the errors with the standard SQL states. Finally, JDBCBridge is no longer aware of the SQLResultSet class. Only Statement implementations are responsible for building of new result sets according to the specification design. Next plan is to completely avoid JDBCBridge logic and transfer it to an inner helper inside the Statement implementations. Closes: #87 Affects: #73, #119
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
The following functions should be implemented (should not raise
SQLFeatureNotSupportedExceptionwhen called with supported resultSetHoldability value, referenced asholdabilitybelow):createStatement(type, concurrency, holdability)prepareCall(sql, type, concurrency, holdability)prepareStatement(sql, type, concurrency, holdability)Also the following methods should be supported:
getHoldability()setHoldability(holdability)The
DatabaseMetaData.supportsResultSetHoldability(holdability)should return appropriate values for bothResultSet.HOLD_CURSORS_OVER_COMMITandResultSet.CLOSE_CURSORS_AT_COMMIT. TheDatabaseMetaData.getResultSetHoldability()should return a default holdability: one of two values above.The issue is about proper APIs support, so it seems that one of the holdability values support is enough. It depends of Tarantool/SQL cursors implementation or, maybe, cursors emulation support of the driver.
The text was updated successfully, but these errors were encountered: