db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein Grovlen - Sun Norway <Oystein.Grov...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Tue, 14 Mar 2006 10:15:14 GMT
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

Mime
View raw message