[
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
