Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1130975146.1141036102895.JavaMail.jira@ajax.apache.org>
Date: Mon, 27 Feb 2006 11:28:22 +0100 (CET)
From: "Fernanda Pizzorno (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-690) Add scrollable, updatable,
 insensitive result sets
In-Reply-To: <298084043.1131470779804.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12367929 ] 

Fernanda Pizzorno commented on DERBY-690:
-----------------------------------------

Daniel wrote:
_______

This also seems closely tied to implementing the ResultSet.refreshRow() method, if we continue with the proposed
implementation and document it, then a natural work-around would be to tell the application to issue a refreshRow(),
but Derby doesn't support it :-(. Of course if refreshRow was implemented, then we possibly wouldn't need to document
this as a refreshRow() could be called after an updateRow() to present the correct information.
________

I do not think implementing the ResultSet.refreshRow() method would help in this case. We are implementing result sets
of type TYPE_SCROLL_INSENSITIVE and according to the "JBDC API Tutorial and Reference, Third Edition" p.759, the 
refreshRow() mothod does nothing for result sets of type TYPE_SCROLL_INSENSITIVE. Maybe you were thinking of the
refreshRow() semantics for sensitive result sets.

I think we should decide whether the effects of a trigger (or other mechanism that can modify columns on an UPDATE 
statement) constitute "own" or "others" changes, and whether we want the result sets of type TYPE_SCROLL_INSENSITIVE 
to be sensitive to "own" updates and deletes or not.


> 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