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] Updated: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Tue, 07 Mar 2006 17:36:40 GMT
     [ http://issues.apache.org/jira/browse/DERBY-690?page=all ]

Dag H. Wanvik updated DERBY-690:

    Attachment: writeup-v3.html

I just uploaded v3 of the write-up to address Øystein's comments.
See also answers inlined.

Øystein wrote:
> Some comments/questions to the write-up:
> * Updatability, 2nd paragraph:  I think you should explain why
>   navigations to new rows and previously fetched rows needs to be
>   handled differently.

This paragraph has been changed, see writeup-v3
> * Isolation level read-uncommitted/read-committed, 2nd paragraph:
>   - 1st sentence: "open" instead of "opened"?


>   - "The result set may overwrite data in an updateRow() ... "  I do
>     not understand what you try to say here.  Do you mean that
>     updateRow may overwrite data that has been changed after the row
>     was read by the result set?  (In other words, you are talking
>     about data in the database, not data in an updateRow.)
>   - Last sentence: I would reformulate to say that only changed
>     columns are written to the database on updateRow().

This 2nd paragraph has been changed, see writeup-v3.

>   - Is there really anything particular about result sets in this
>     context?   Would not the same discussion be relevant for any
>     multi-statement transaction?

No, I agree. I added these paragraphs:

    Note that these effects will also apply to rows changed by our own
    transaction if made via separate UPDATE statements, no matter what
    isolation level is active.

    If such effects are an issue, the user could increase the
    isolation level (and/or make own transaction behave!) For Derby,
    at some point in the future we might want to add updatable
    sensitive result sets and/or add some syntax to allow extra
    locking for rows in updatable result set.


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