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 17:41:11 GMT
    [ 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

> That's from a SQL point of view, then from JDBC we have in JDBC 3.0
> spec.  (section, 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,
> be one of CONCUR_READ_ONLY and CONCUR_UPDATABLE. The holdability can
> JDBC allows the full cross product of these. SQL 2003 prohibits the
> 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:
For more information on JIRA, see:

View raw message