[ 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, writeup-v1.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
