db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Wed, 01 Mar 2006 13:49:49 GMT
    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12368283 ] 

Dag H. Wanvik commented on DERBY-690:

(reposting a mail comment by Dan here. -Dag)

Øystein Grøvlen wrote:

> Daniel John Debrunner (JIRA) wrote:
>> Agreed, it's the same issue in my mind, and allowing such a row in a
>> ResultSet would be wrong. I believe after an update the row in the
>> ResultSet must reflect the state of the row in the database. Hence,
>> like Oracle, Derby should perform the equivalent of a refreshRow.
> I think such an implementation kind of blurs the concept of sensitivity.
>   You get a result set that is sensitive to some, but not all, changes
> performed by other statements in the same transaction.  The available
> metadata for a result set, does not provide a way to describe such
> behavior. 

Not sure I agree, I think insensitive result sets are like that anyway.
Taking this from the spec, that Dag quoted:

> - JDBC 3.0 spec: "The result set is insensitive to changes made to the
> underlying data source while it is open. It contains the rows that
> satisfy the query at either the time the query is executed or as the
> rows are retrieved." 

Since a row value can be from the time the query was executed or as the
rows are retrieved, I can have a ResultSet where some rows show the
effect of a statement, while other rows do not show the effect of the
same statement. Not sure an implicit refreshRow() after an updateRow()
makes the situation any different.

> This whole discussion makes me think that the only sensible
> way to implement an insensitive result set is to not make own changes
> visible.  At least, that would give a clean implementation with a
> behavior that is easy to understand.

That's one clean option.


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