[ 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
