Issue Details (XML | Word | Printable)

Key: JDBC-296
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Mark Rotteveel
Reporter: Mark Rotteveel
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Jaybird JDBC Driver

Refactor implementation of {call ...} escape for better support in Statement, PreparedStatement and CallableStatement

Created: 03/Jan/13 01:09 PM   Updated: 09/Jun/18 12:48 PM
Component/s: JDBC driver
Affects Version/s: Jaybird 2.1.6, Jaybird 2.2, Jaybird 2.2.1
Fix Version/s: Jaybird 5

Issue Links:
Relate


 Description  « Hide
The {call ...}-escape should be supported on Statement, PreparedStatement and CallableStatement (in various degrees), the current implementation is inefficient for CallableStatement (it parses the statement two or three times) and it looks like it might shuffle the parameter order in the case of {?= call ...} (not 100% sure), and support under Statement and PreparedStatement seems accidental (and there are no tests).

Also the existing implementation considers parentheses around the parameter list to be optional; they are required by the syntax defined in section 13.4.4 of the JDBC spec (they are only optional if there are no parameters).

See also http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-January/000029.html

================================
ORIGINAL TEXT:
Currently the {call ... } escape is supported for Statement and PreparedStatement as well. It should only be supported for CallableStatement. This will also reduce the complexity of parsing (with repeated parsing) as described in JDBC-292.

Implementation-wise the JDBCEscape parser should be changed to simply leave the {call ...} and {? = call ...} escapes untouched (but it should parse the escapes nested inside the call, leaving it upto Firebird to throw an excepion when it receives {call ...} untranslated. Then only the FBCallableStatement/FBEscapedCallParser implementation should translate the call escape to the appropriate Firebird specific call.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Mark Rotteveel made changes - 03/Jan/13 01:09 PM
Field Original Value New Value
Fix Version/s Jaybird 2.3 [ 10440 ]
Mark Rotteveel made changes - 03/Jan/13 01:10 PM
Description Currently the {call ... } escape is supported for Statement and PreparedStatement as well. It should only be supported for CallableStatement. This will also reduce the complexity of parsing (with repeated parsing) as described in JDBC-292.

Implementation-wise the JDBCEscape parser should be changed to simply leave the {call ...} and {? = call ...} escapes untouched (but it should parse the escapes nested inside the call, leaving it upto Firebird to throw an excepion when it receives {call ...} untranslated. Then only the FBCallableStatement/FBEscapedCallParser implementation should translate the call escape to the appropriate escape.
Currently the {call ... } escape is supported for Statement and PreparedStatement as well. It should only be supported for CallableStatement. This will also reduce the complexity of parsing (with repeated parsing) as described in JDBC-292.

Implementation-wise the JDBCEscape parser should be changed to simply leave the {call ...} and {? = call ...} escapes untouched (but it should parse the escapes nested inside the call, leaving it upto Firebird to throw an excepion when it receives {call ...} untranslated. Then only the FBCallableStatement/FBEscapedCallParser implementation should translate the call escape to the appropriate Firebird specific call.
Mark Rotteveel made changes - 03/Jan/13 01:15 PM
Link This issue is related to JDBC-292 [ JDBC-292 ]
Mark Rotteveel made changes - 03/Jan/13 04:55 PM
Summary Refactor support for {call ...} escape support so it can no longer be used from Statement and PreparedStatement. Refactor support for {call ...} escape support for better support in Statement, PreparedStatement and CallableStatement
Description Currently the {call ... } escape is supported for Statement and PreparedStatement as well. It should only be supported for CallableStatement. This will also reduce the complexity of parsing (with repeated parsing) as described in JDBC-292.

Implementation-wise the JDBCEscape parser should be changed to simply leave the {call ...} and {? = call ...} escapes untouched (but it should parse the escapes nested inside the call, leaving it upto Firebird to throw an excepion when it receives {call ...} untranslated. Then only the FBCallableStatement/FBEscapedCallParser implementation should translate the call escape to the appropriate Firebird specific call.
The {call ...}-escape should be supported on Statement, PreparedStatement and CallableStatement (in various degrees), the current implementation is inefficient for CallableStatement (it parses the statement two or three times) and it looks like it might shuffle the parameter order in the case of {?= call ...} (not 100% sure), and support under Statement and PreparedStatement seems accidental (and there are no tests).

Also the existing implementation considers parentheses around the parameter list to be optional; they are required by the syntax defined in section 13.4.4 of the JDBC spec (they are only optional if there are no parameters).

See also http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-January/000029.html

================================
ORIGINAL TEXT:
Currently the {call ... } escape is supported for Statement and PreparedStatement as well. It should only be supported for CallableStatement. This will also reduce the complexity of parsing (with repeated parsing) as described in JDBC-292.

Implementation-wise the JDBCEscape parser should be changed to simply leave the {call ...} and {? = call ...} escapes untouched (but it should parse the escapes nested inside the call, leaving it upto Firebird to throw an excepion when it receives {call ...} untranslated. Then only the FBCallableStatement/FBEscapedCallParser implementation should translate the call escape to the appropriate Firebird specific call.
Mark Rotteveel made changes - 03/Jan/13 04:56 PM
Summary Refactor support for {call ...} escape support for better support in Statement, PreparedStatement and CallableStatement Refactor implementation of {call ...} escape for better support in Statement, PreparedStatement and CallableStatement
Mark Rotteveel made changes - 19/Jan/13 11:51 AM
Link This issue relate to JDBC-229 [ JDBC-229 ]
Mark Rotteveel made changes - 19/Jan/13 12:04 PM
Link This issue relate to JDBC-297 [ JDBC-297 ]
Mark Rotteveel made changes - 18/Oct/15 09:48 AM
Link This issue relate to JDBC-402 [ JDBC-402 ]
Mark Rotteveel made changes - 06/Apr/16 09:03 AM
Fix Version/s Jaybird 3.1 [ 10441 ]
Fix Version/s Jaybird 3.0 [ 10440 ]
Mark Rotteveel made changes - 09/Jun/18 12:48 PM
Fix Version/s Jaybird 5 [ 10871 ]
Fix Version/s Jaybird 4 [ 10441 ]