db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernanda Pizzorno (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Mon, 27 Feb 2006 10:28:22 GMT
    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12367929 ] 

Fernanda Pizzorno commented on DERBY-690:
-----------------------------------------

Daniel wrote:
_______

This also seems closely tied to implementing the ResultSet.refreshRow() method, if we continue
with the proposed
implementation and document it, then a natural work-around would be to tell the application
to issue a refreshRow(),
but Derby doesn't support it :-(. Of course if refreshRow was implemented, then we possibly
wouldn't need to document
this as a refreshRow() could be called after an updateRow() to present the correct information.
________

I do not think implementing the ResultSet.refreshRow() method would help in this case. We
are implementing result sets
of type TYPE_SCROLL_INSENSITIVE and according to the "JBDC API Tutorial and Reference, Third
Edition" p.759, the 
refreshRow() mothod does nothing for result sets of type TYPE_SCROLL_INSENSITIVE. Maybe you
were thinking of the
refreshRow() semantics for sensitive result sets.

I think we should decide whether the effects of a trigger (or other mechanism that can modify
columns on an UPDATE 
statement) constitute "own" or "others" changes, and whether we want the result sets of type
TYPE_SCROLL_INSENSITIVE 
to be sensitive to "own" updates and deletes or not.


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