db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1087) Updatable result sets behave different depending on the type of query used to generate the result set
Date Tue, 09 May 2006 09:55:24 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1087?page=comments#action_12378595 ] 

Andreas Korneliussen commented on DERBY-1087:
---------------------------------------------

I have downloaded the patch, and first only applied the test, to see that it failed before
taking in the changes in the engine. It seems like the test now fails with a ClassCastException
in TableScanResultSet:
There was 1 error:
1) testUpdateUpdatedTuple(org.apache.derbyTesting.functionTests.tests.jdbcapi.URCoveringIndexTest)java.lang.ClassCastException
        at org.apache.derby.impl.sql.execute.TableScanResultSet.getRowLocation(TableScanResultSet.java:907)
        at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getRowLocation(ProjectRestrictResultSet.java:408)
        at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getRowLocation(ScrollInsensitiveResultSet.java:942)
        at org.apache.derby.impl.sql.execute.CurrentOfResultSet.getNextRowCore(CurrentOfResultSet.java:120)
        at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:258)
        at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:123)
        at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:450)
        at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:272)
        at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361)
        at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181)
        at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584)
        at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:176)
        at org.apache.derbyTesting.functionTests.tests.jdbcapi.URCoveringIndexTest.testUpdateUpdatedTupleWithCoveringIndex(URCoveringIndexTest.java:96)
        at org.apache.derbyTesting.functionTests.tests.jdbcapi.URCoveringIndexTest.testUpdateUpdatedTuple(URCoveringIndexTest.java:119)

I have been able to reproduce this in a debugger. TableScanResultSet does a cast to RowLocation
in line 907, however the DataValueColumn is at the time of the failure a SQLInteger, not a
RowLocation.

After applying the patch, I did not get any failures.


> Updatable result sets behave different depending on the type of query used to generate
the result set
> -----------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1087
>          URL: http://issues.apache.org/jira/browse/DERBY-1087
>      Project: Derby
>         Type: Bug

>   Components: JDBC, SQL
>     Reporter: Fernanda Pizzorno
>     Assignee: Fernanda Pizzorno
>  Attachments: derby-1087.diff, derby-1087.stat
>
> Running the following code with different queries in the first statement produces different
results.
> Where t1 has two columns: "a" of type int is the primary key, and "b" of type varchar(50);
and contains 10 rows of data.
>             Statement st1 = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, 
>                     ResultSet.CONCUR_UPDATABLE);
>             Statement st2 = conn.createStatement();
>             
>             ResultSet rs = st1.executeQuery("SELECT a, b FROM t1");
>             rs.next();
>             rs.next();
>             st2.executeUpdate("UPDATE t1 SET a = a + 20 WHERE a = " + 
>                     rs.getInt(1));
>             try {
>                 rs.updateInt(1, rs.getInt(1) + 30);
>                 rs.updateRow();
>             } catch (SQLException se) {
>                 System.out.println(se.getMessage());
>             }
>             rs.close();
>             
>             rs = st2.executeQuery("SELECT a FROM t1");
>             while(rs.next()) {
>                 System.out.println("A = " + rs.getInt(1));
>             }
>             rs.close();
>             
>             st2.close();
>             st1.close();
> If the first query is "select a, b from t1", the output will be:
> A = 1
> A = 3
> A = 4
> A = 5
> A = 6
> A = 7
> A = 8
> A = 9
> A = 10
> A = 32
> If the first query is "SELECT a, b FROM t1 WHERE a <= 5", the output will be:
> Cursor 'SQLCUR0' is not on a row.
> A = 1
> A = 3
> A = 4
> A = 5
> A = 6
> A = 7
> A = 8
> A = 9
> A = 10
> A = 22
> If the first query is "SELECT a FROM t1", the output will be:
> Cursor 'SQLCUR0' is not on a row.
> A = 1
> A = 3
> A = 4
> A = 5
> A = 6
> A = 7
> A = 8
> A = 9
> A = 10
> A = 22

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message