[
https://issues.apache.org/jira/browse/DERBY-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537842
]
Mamta A. Satoor commented on DERBY-3139:
----------------------------------------
I want to summarize the status of this Jira entry.
When I filed this Jira entry, there were 2 items that needed to be tackled.
1)When PreparedStatement does not have any parameter, and a user tries to use
setObject(int,Object,int) on it, Embedded threw SQL State 07009 whereas Network
Server threw XCL13. I fixed this change in behavior as part of DERBY-3046
(trunk revision 588527).
2)The second issue is specific to Network Server.
If the PreparedStatement has non-zero number of parameters and user tries to
use setObject with out of range parameter number, Network Server throws
XCL13(which is same as Embedded Server). This exception is thrown by method
org.apache.derby.client.am.PreparedStatement:checkForValidParameterIndex which
is called at line 1439 in
org.apache.derby.client.am.PreparedStatement:setObject.
But if the user tries to use say setString with out of range parameter number,
Network Server throws XCL14(Embedded throws XCL13). This is because for
setString in NetworkServer, we do not call
org.apache.derby.client.am.PreparedStatement:checkForValidParameterIndex.
Instead, we call (line 931 in
org.apache.derby.client.am.PreparedStatement:setString)
org.apache.derby.client.am.ColumnMetaData:checkForValidColumnIndex which throws
XCL14. I can't change
org.apache.derby.client.am.ColumnMetaData:checkForValidColumnIndex to throw
XCL13 because that method is also used for calls like
ResultSetMetaData:isNullable and if isNullable is called with invalid column
number, we do want to throw XCL14.
One way to fix this problem is to have setString call
org.apache.derby.client.am.PreparedStatement:checkForValidParameterIndex just
like setObject but that means that for every setString in Network Server, there
will 2 checks made for valid parameter number. One check will be in
org.apache.derby.client.am.PreparedStatement:checkForValidParameterIndex and
next check will be in
org.apache.derby.client.am.ColumnMetaData:checkForValidColumnIndex. If the
parameter number indeed is invalid, it will be caught in the parameter check in
PreparedStatement:checkForValidParameterIndex but if it is valid, then we will
do unnecessary check for parameter number again in
ColumnMetaData:checkForValidColumnIndex.
Since all this is happening at compile time, may be it is ok to let the
checking happen 2 times. I haven't spent enough time on this to figure out if
we can do this in a different way so that we always throw XCL13 when the
parameter number for setObject and setString is out of range. Also, the same
issue exists for setShort, setInt, setBlob etc
> setObject and other setXXX methods on PreparedStatement throw different
> exceptions in Network Server when parameter number is out of range
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3139
> URL: https://issues.apache.org/jira/browse/DERBY-3139
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Affects Versions: 10.3.1.4, 10.4.0.0
> Reporter: Mamta A. Satoor
> Assignee: Mamta A. Satoor
>
> In Network Server, when a user executes PreparedStatement.setObject with out
> of range parameter number, the exception thrown is XCL13 but when the user
> tries PreparedStatement.setString with out of range parameter number, the
> exception thrown in Network Server is XCL14. We should throw same exception
> for both the cases.
> The reason for this difference in behavior is
> client.am.PreparedStatement.setObject calls checkForValidParameterIndex for
> parameter number checking and that method throws exception XCL13.
> All the other PreparedStatement.setXXX methods end up calling
> getColumnMetaDataX().getColumnType(parameterIndex); which results into call
> to client.am.ColumnMetaData:getColumnType() which in turn calls
> checkForValidColumnIndex for parameter number checking and that method throws
> exception XCL14.
> I am adding a test case for this in derbynet.PrepareStatementTest.
> I am wondering if the community has any objection to one of the error message
> getting changed into another. I wonder if it will cause user applications to
> break because they rely of different error message. And if not, any ideas on
> which one we should get rid of?
> Also, the exception thrown for these 2 cases in Embedded server is same but
> it is not XCL14 or XCL13. I will work on entering another jira entry for
> difference in exception for embedded and network server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
