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.
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?
positionAtRowLocation() returns false if the row has been deleted.
b) I am still a bit uncomfortable with the method names in the
following call path:
setRowLocation()
positionAtRowLocation()
reopenScanByRecordHandleAndSetLocks().
The lower levels makes more happen than the names of the high
level methods indicates.
Remember these are methods in different modules, and we should try to keep the names of the methods within modules consistent with the module.
I.e in SQL execution layer, methods for getting RowLocation is called getRowLocation().
getRowLocation() gives you the position of the current record of the
scan. I think the problem is that the opposite, setRowLocation(), could
be interpreted in two different ways:
1. Change the scan position (current record)
2. Change the position of the current record
The fact that positionAtRowLocation() also sets locks, is natural in the store.
Also next() sets locks. You set locks in a scan without mentioning it in the
method names.
You are right.
--
Øystein Grøvlen
