db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Wed, 01 Mar 2006 16:48:44 GMT
    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12368311 ] 

Daniel John Debrunner commented on DERBY-690:
---------------------------------------------

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.

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

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.

Dag said:
----
b) A refresh would also make visible other changes to the row
   performed by others (that is other updates, not made by the trigger
   action). One could possibly filter out such changes, to get just
   the net effect of any trigger action, but it seems esoteric. It
   could also be row internally inconsistent, as pointed out before in
   this thread. That is, to get row internal consistency, we need to
   make "other's" changes for the row visible (violation in my view). 
----
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
:-)]

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.






> 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