db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5533) Client differs from embedded when rs.updateInt overflows: 22015 vs 22003
Date Wed, 14 Dec 2011 01:00:39 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dag H. Wanvik updated DERBY-5533:

    Attachment: derby-5533-test.diff

Uploading derby-5522-test which extends the repro into a full fledged test of upper lower
bound checking on the conversions in ResultSet#setXXX and #getXXX.

I have checked that all usages of LossOfPrecisionConversionException is covered by these tests,
so changing that exception should be safe.

Up till now I have made this a patch of UpdateXXXTest, which may not be entirely suitable
now that we're testing getXXX as well. Poked around, but found only ParameterMappingTest asserting
against the SQL state 22003. Should I try to move these new tests over there, possibly make
a new test, or just leave them inside UpdateXXXTest? 
> Client differs from embedded when rs.updateInt overflows: 22015 vs 22003
> ------------------------------------------------------------------------
>                 Key: DERBY-5533
>                 URL: https://issues.apache.org/jira/browse/DERBY-5533
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>            Reporter: Dag H. Wanvik
>            Priority: Minor
>         Attachments: derby-5533-repro.diff, derby-5533-test.diff
> stm.executeUpdate("create table t(i smallint)");
> stm.executeUpdate("insert into t values 1,2,3,4");
> ResultSet rs = stm.executeQuery("select i from t");
> rs.next();
> try {
>     rs.updateInt(1, 100000);
> } catch (SQLException e) {
>     // client: 22015 vs embedded 22003
> }
> According to the standard, 22015 should be used for INTERVALs ("interval field overflow").
22003 seems more correct, the standard uses that for "numeric value out of range".

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message