[ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12368283 ]
Dag H. Wanvik commented on DERBY-690:
-------------------------------------
(reposting a mail comment by Dan here. -Dag)
Øystein Grøvlen wrote:
> Daniel John Debrunner (JIRA) wrote:
>
>> Agreed, it's the same issue in my mind, and allowing such a row in a
>> ResultSet would be wrong. I believe after an update the row in the
>> ResultSet must reflect the state of the row in the database. Hence,
>> like Oracle, Derby should perform the equivalent of a refreshRow.
>
>
> I think such an implementation kind of blurs the concept of sensitivity.
> You get a result set that is sensitive to some, but not all, changes
> performed by other statements in the same transaction. The available
> metadata for a result set, does not provide a way to describe such
> behavior.
Not sure I agree, I think insensitive result sets are like that anyway.
Taking this from the spec, that Dag quoted:
> - JDBC 3.0 spec: "The result set is insensitive to changes made to the
> underlying data source while it is open. It contains the rows that
> satisfy the query at either the time the query is executed or as the
> rows are retrieved."
Since a row value can be from the time the query was executed or as the
rows are retrieved, I can have a ResultSet where some rows show the
effect of a statement, while other rows do not show the effect of the
same statement. Not sure an implicit refreshRow() after an updateRow()
makes the situation any different.
> This whole discussion makes me think that the only sensible
> way to implement an insensitive result set is to not make own changes
> visible. At least, that would give a clean implementation with a
> behavior that is easy to understand.
That's one clean option.
Dan.
> 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
|