db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3139) setObject and other setXXX methods on PreparedStatement throw different exceptions in Network Server when parameter number is out of range
Date Fri, 26 Oct 2007 06:03:50 GMT

    [ 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.


Mime
View raw message