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-1251) cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
Date Wed, 10 May 2006 08:59:05 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12378856 ] 

Andreas Korneliussen commented on DERBY-1251:
---------------------------------------------

> - //After a delete, the ResultSet will be positioned right before
> - //the next row.
> - rowData = null;
> - currentRow = null;
> + //For forward only resultsets, after a delete,
> + // the ResultSet will be positioned right before the next row.
> + if (getType() == TYPE_FORWARD_ONLY) {
> + currentRow.setRowArray(null);
> + } else {
> + movePosition(RELATIVE, 0, "relative");
> + } 
> 
> According to JDBC 3.0 specification section "14.2.4.2 Deleting a Row", after a
> deleteRow has been called, the cursor will be positioned before the next valid
> row. Is there a reason to make this comment specific to forward only result
> sets? 

This is a good point. For FORWARD_ONLY resultsets, this means that the cursor is not on a
row (i.e all getXXX(..) methods throws exception), and when calling next the cursor will be
positioned on the next row.
For SCROLL INSENSITIVE cursors, I am a bit unsure if the current row (which has been deleted)
is valid or not.  If it is valid, it is correct to be on the current row, since it is before
the next valid row. If it is considered as invalid the cursor should be position somewhere
inbetween the current row and the next row (i.e not on a row). 
Then the behavior would be that: calling next() will give the next row, calling previous will
give the previous row, and calling relative(0) will give the current invalid (deleted) row
in scroll insensitive resultsets. 

However I choose to not deal with this in this patch. The call to movePosition(RELATIVE..)
should not be part of the patch, it could be added in another patch, i.e  if we choose to
consider the current row as a valid row after it has been deleted.


> cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
> -------------------------------------------------------------------------------------------
>
>          Key: DERBY-1251
>          URL: http://issues.apache.org/jira/browse/DERBY-1251
>      Project: Derby
>         Type: Bug

>   Components: JDBC, Network Client
>     Versions: 10.2.0.0
>     Reporter: Andreas Korneliussen
>     Assignee: Andreas Korneliussen
>     Priority: Minor
>  Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat,
derbyall_report.txt, derbyall_report.txt
>
> If an application does the following:
> rs.updateInt(1, newValueCol1);
> rs.updateRow();
> rs.updateInt(2, newValueCol2);
> rs.cancelRowUpdates();
> Then, when calling rs.getInt(1), it will return the old value. Instead it should return
the new value.
> Workaround: after calling rs.updateRow(), the application could call rs.relative(0).
> This problem does not affect forward only resultsets, since after an updateRow() they
get positoned before the next row, leaving it impossible to do anything with the current row.

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