db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Fri, 24 Feb 2006 13:42:40 GMT
    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12367654 ] 

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.

> Does the answer have any effect on the "own vs others" updates being
> visible?

Yes, I would say so. I tried to see if JDBC had anything to say on
whether a trigger action would constitute an "own" change, but could
not find anything. I think it is questionable to treat it is an "own"
change, since JDBC classifies even changes via a positioned update on
the result set's cursor as "others" (although we treat it as "own" in
our implementation as stated in the write-up). 
That is, "others" are not limited to other transactions, but include
other changes made through other statement objects.

Since a trigger executes a separate SQL statement one could argue that
this change happens via another statement object, and thus constitutes
an "others" change. But I don't think the answer is obvious. Since SQL
doesn't cater for updatable result sets for scrollable insensitive
cursors, there is no help to be gleaned from the standard. Will update
the write-up for now.


> 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


Mime
View raw message