db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Fri, 24 Feb 2006 16:44:39 GMT
    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12367668 ] 

Daniel John Debrunner commented on DERBY-690:

> Dag H. Wanvik commented on DERBY-690:
> -------------------------------------
> Dan wrote:
>>So, to confirm, this means the updated row in the result set will
>>reflect the state of the row in the database and not the values set
>>by the updateRow() call? Good to state here exactly what the
>>behaviour is expected to be. So if I update a column to value 10
>>using rs.updateRow(), but some processing in the SQL positioned
>>update (say a fired trigger) results in the column being stored as
>>20, then will the ResultSet have 20 or 10? 
> No, any further changes resulting from actions of the trigger will not be 
> reflected in the result set in the current implementation.

My thought here is that the updated row in the ResultSet would then
reflect a state of the database that never occurred. This seems in
conflict with all isolation levels except read-uncommitted. I can't
think of another situation where an application using Derby can see a
row in that state (excluding read-uncommitted).

> [Dag's useful own vs. others discussion snipped]

If "own" means changes made through the ResultSet, then one could say
that side-effect changes are "own", since they resulted from the
ResultSet's updateRow. Since an UPDATE statement and its side-effects
are atomic, then the updateRow must be atomic.

> 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, SURChanges-v1.pdf, sur-proposal.txt,
> JDBC result sets are created with three properties: type, concurrency
> and holdability. The type can be one of TYPE_FORWARD_ONLY,
> be one of CONCUR_READ_ONLY and CONCUR_UPDATABLE. The holdability can
> JDBC allows the full cross product of these. SQL 2003 prohibits the
> 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:
For more information on JIRA, see:

View raw message