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-690) Add scrollable, updatable, insensitive result sets
Date Tue, 14 Mar 2006 09:03:07 GMT
    [ 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().

positionAtRowLocation(..) positions the scan, and locks the row. 


> 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

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(). 

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.


> Add scrollable, updatable, insensitive result sets
> --------------------------------------------------
>
>          Key: DERBY-690
>          URL: http://issues.apache.org/jira/browse/DERBY-690
>      Project: Derby
>         Type: New Feature
>   Components: JDBC
>     Reporter: Dag H. Wanvik
>     Assignee: Dag H. Wanvik
>     Priority: Minor
>  Attachments: DERBY-690-v1.diff, DERBY-690-v1.stat, DERBY-690-v2.diff, DERBY-690-v2.stat,
SURChanges-v1.pdf, sur-proposal.txt, writeup-v1.html, writeup-v2.html, writeup-v3.html
>
> JDBC result sets are created with three properties: type, concurrency
> and holdability. The type can be one of TYPE_FORWARD_ONLY,
> TYPE_SCROLL_INSENSITIVE and TYPE_SCROLL_SENSITIVE. The concurrency can
> be one of CONCUR_READ_ONLY and CONCUR_UPDATABLE. The holdability can
> be one of HOLD_CURSORS_OVER_COMMIT and CLOSE_CURSORS_AT_COMMIT.
> JDBC allows the full cross product of these. SQL 2003 prohibits the
> combination {TYPE_SCROLL_INSENSITIVE, CONCUR_UPDATABLE}, but this
> combination is supported by some vendors, notably Oracle.
> Currently, Derby supports JDBC result sets in a limited
> way. Holdability is supported. Furthermore, the following is
> supported: 
> 	   - forward-only, read-only 
> 	   - forward-only, updatable (update, delete, but not insert)
> 	     Also, in the network driver, support for some data types
> 	     conversions is missing.
> 	   - scroll insensitive, read-only
> We (Fernanda and Andreas will cooperate with me on this) propose a
> plan to add support for the combination:
> 	   - scroll insensitive, updatable
> for both the embedded driver and the network client driver. 
> As a part of this we would also like to add the missing insert
> operation to the {forward-only, updatable} result sets (JIRA-100), and
> remove the requirement for an explicit "FOR UPDATE" clause in the SQL
> query to achieve updatability if CONCUR_UPDATABLE is specified
> (JIRA-231).
> The full proposal text is uploaded as an attachment, including a proposed
> functional specification.
> This JIRA will  be used to track sub-issues for this effort. The sub-issues will be linked
back to this issue.

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