db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-2515) Network client does not retain the INOUT parameter value change for subsequent execution
Date Thu, 31 Mar 2011 12:09:05 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013940#comment-13013940

Knut Anders Hatlen commented on DERBY-2515:

Thanks for the explanations, Rick.

1) I asked because I wasn't sure if the Integer objects originated from user input. If they
come from the server, and the server says the type is SMALLINT, I think we should trust the
server. So I'm comfortable with the current code.

2) Right, it looks like Cursor.getObject() raises an exception if it doesn't understand the
JDBC type of the column, which would indicate a bug. And adding a new checked exception type
to the throws clause is a bit awkward here, I agree, at least when it's just to handle a case
that's not supposed to happen. Narrowing it down to SqlException only, and possibly also making
the try block smaller so that it only encloses the expression that may raise the exception,
sounds like a good improvement. For extra bonus, you might want to call initCause() on the
wrapper to preserve the stack trace if this is ever going to happen.

> Network client does not retain the INOUT parameter value change for subsequent execution
> ----------------------------------------------------------------------------------------
>                 Key: DERBY-2515
>                 URL: https://issues.apache.org/jira/browse/DERBY-2515
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:
>            Reporter: Kathey Marsden
>            Priority: Minor
>              Labels: derby_triage10_8
>             Fix For:
>         Attachments: Test_2515.java, derby-2515-01-ac-copyINOUTreturnValues.diff
>  If I set a INOUT parameter to a value (say 12.3) and it gets 
> modified by the procedure to another value (say 45.6) then on 
> the next execution
>      of the same CallableStatement, embedded maintains the 
> current value (45.6), while network server reverts to the 
> former value (12.3).  
> This issue was found while converting the test lang/procedure.java.  See references to
this issue in the converted LangProcedureTest.java

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message