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 Wed, 01 Mar 2006 15:25:42 GMT
    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12368299 ] 

Dag H. Wanvik commented on DERBY-690:
-------------------------------------

Dan> I need to think a little more about why you think oracle's
Dan> behaviour is not JDBC compliant (excluding supporting refreshRow
Dan> with an insensitive rs)

Dan, did you reach any conclusion here? I would like to settle this
issue so we can move on with the review of the patch. I do understand
your concern about row internal consistency, but I admit I am torn,
since to get the effect of a trigger on the row being updated, we
would need to refresh the row and this is in violation of the JDBC
spec in two ways in my view:

a) The definition of visibility of own changes in the specification:

   "One's own updates are visible if an updated column value can be
   retrieved by calling getXXX() following a call to updateXXX()."
   [from the JDBC 2.0 spec, this explanation of own changes has been
   since been removed, though, but is still in the tutorial book,
   which purports to expound on JDBC 3.0]

   Note, this quote does not mandate that updateRow() has been
   performed yet, so no side effects could be visible at this point;
   they did not happen yet. 

   That is not to say that the wording precludes that the updateRow
   could lead to further changes to the column(s), than those
   resulting from the direct updateXXX actions, but any such change
   would need to be a result of an "own" change for it to be legal for
   an insensitive result set. And I would still contend that any
   actions to the underlying data by the trigger represents an
   "others" change.

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

In summary, I think we should either

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

   - keep the current implementation (reflect only such changes as are
     made directly through the updateXXX methods. 

I guess I am OK with either solution (just as long as we are clear on
if/how we break JDBC), but I would like to move on and would
appreciate your final conclusion :)

I don't want to remove visibility up updates altogether, as Øystein
proposed, as I think it makes for a less attractive/useful solution.

If anybody else has a considered opinion on this, please raise your
voices 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, 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