Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <17832494.1193378630578.JavaMail.jira@brutus>
Date: Thu, 25 Oct 2007 23:03:50 -0700 (PDT)
From: "Mamta A. Satoor (JIRA)" <jira@apache.org>
To: derby-dev@db.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
In-Reply-To: <2095498.1192821890771.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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