Oystein Grovlen - Sun Norway wrote:
Andreas Korneliussen (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12370325
]
Andreas Korneliussen commented on DERBY-690:
--------------------------------------------
11.2 positionAtRowLocation()
a) Why can not clients use the existing reopenScanByRowLocation
instead?
reopenScanByRowLocation(..) let the user reopen the scan and start
scanning from the RowLocation specified. After a call to
reopenScanByRowLocation(..) the rowLocation is not locked, the page is
not latched, and the user need to call next() to get the next record.
This will actually be the next record after the rowLocation specified
in reopenScanByRowLocation().
Is this correct? OpenConglomerate.latchPageAndRepositionScan() will
position on the record before the specified position.
Agree.
positionAtRowLocation(..) positions the scan, and locks the row.
So does the combination of reopenScanByRowLocation() and next().
12. GenericScanController
12.1 reopenScanByRecordHandleAndSetLocks()
a) If I have understood things correct, when a scan is initially
opened, the first row is not locked. Locking happen on the
subsequent next(). Why could not a similar scheme be used
here? That is, reopen positions just before the specified row
and a subsequent call to next is performed to actually lock
it. Looking at fetchRows() and the methods it calls, there
seems to already exist code to handle a repositioned scan.
(The combination of SCAN_INIT and a set record posisiton).
The combination of SCAN_INIT and a set record position will on the
next() call move the rowlocation to the next row, not to the set
record position.
If you position to a rowlocation which points to a previous row, and
call next you may risk:
* on the next() call you skip the row if it has been deleted and
return another row
But could not this be detected and handled by the caller?
It could theoretically be detected by calling fetchRowLocation() after
the next() and comparing it with the RowLocation specified.
Instead of scancontroller.positionAtRowLocation(rowLoc) you would get:
scancontroller.reopenScanByRowLocation(rowLoc);
scancontroller.next();
RowLocation cmp = scancontroller.newRowLocationTemplate();
scancontroller.fetchLocation(cmp);
if (!cmp.equals(rowLoc)) { // row deleted ?
// need to go back to avoid that next() skips a row
scancontroller.reopenScanByRowLocation(rowLoc);
return false;
} else {
return true;
}
I think it is preferrable to provide the positionAtRowLocation(..) method.
positionAtRowLocation() returns false if the row has been deleted.
Andreas
