[ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12368322 ]
Dag H. Wanvik commented on DERBY-690: ------------------------------------- Dan said: > I think one difference is I don't see the argument for triggered > actions being "other changes" Triggered actions are atomic with a > statement (in this case a SQL UPDATE). Since ResultSet.updateRow() > is logically a SQL UPDATE for Derby, and triggered actions are > atomic with the UPDATE, then triggered actions have to be considered > "own" changes. They resulted from the ResultSet.updateRow, and if > the updateRow fails then the triggered actions are rolled back. Yes, this is the crux of the matter :) Too bad the standard isn't more explicit! > > That's from a SQL point of view, then from JDBC we have in JDBC 3.0 > spec. (section 14.2.4.2, for some reason this is no mention of > "other changes" in the update section). >> The method DatabaseMetaData.othersDeletesAreVisible(int type) checks >> whether deletions made by others (another transaction or another >> ResultSet object in the same transaction) are visible to ResultSet >> objects of the specified type. > I assume a mistake was made here, changes can be made by Statements > as well as ResultSet objects in the same transaction. Even with Agreed, must be a mistake. > that, triggered actions do *not* fall into either category, they are > not made in another transaction and they are not made by other JDBC > objects in the same transaction. Thus, triggered actions are not > "other" changes. Given the vagueness of the definition, it is hard to conclude. I noticed that the Oracle doc explanation called it "external change" (ie "others"). I agree that your interpretation makes sense from a logical perspective, though (atomicity). Iff we assume the 2.1 wording is wrong, I guess we have the latitude we need for accepting it as an "own" change. > The wording that Andreas found in the JDBC 2.1 spec is another > issue, I think it just looks wrong, I think own or other changes is > a reflection of changes made at the database engine, not those just > proposed in a ResultSet. The fact that this text was removed in > subsequent versions might support that. Yes, possibly. > While a refreshRow() does make "other" changes visible, I see that > as in-line with JDBC's defintion of insensitive, which is not the > same a SQL's [more on that in the other thread :-)] If we allow trigger's changes to be "own", I guess we need to swallow this one, too :) I wish JDBC had something like ODBC's keyset driven cursors sets, then we could happily refresh at each repositioning ;) > > Dag also said: > --- [as one option] > - go for your suggestion, that is, do an implicit refresh after > each updateRow (or positioned UPDATE), even if this breaks JDBC > semantics a bit, *or* > So, I've only ever said the implicit refresh after an updateRow. Doing it > after a positioned UPDATE would be wrong as that is an "other" change, > it's executed by a different JDBC Statement object. In our implementation, a positioned UPDATE (for the same result set) is considered an "own" change, cf. the write-up. It would be hard to differentiate since the implementation of updateRow piggybacks the positioned update. If we are all OK with it, let's do the refresh solution. > 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
