Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1430763571.1140661746535.JavaMail.jira@ajax.apache.org>
Date: Thu, 23 Feb 2006 03:29:06 +0100 (CET)
From: "Daniel John Debrunner (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_12367458 ] 

Daniel John Debrunner commented on DERBY-690:
---------------------------------------------

Comments on writeup-v1.html.

In the conflict section you treat read uncommitted and read-committed as the same, but read-uncommitted isolation level will not get any locks, at least that's what I thought. Should we even allow updateable result sets when the isolation level is read-uncommitted?

The read uncommitted/read-committed talks about the row being deleted, but the row being deleted by the same transaction is not discussed in the serializable/repeatable read section.

" If the user renavigates to the row, the lock will be reset," - what does reset mean here, is it the lock will be obtained again?

I didn't see any explaination how how the update or delete is performed using the RowLocation. The forward only ResultSet uses positioned SQL statements to perform the update, is that the case here? If not, how are you guaranteeing all the associated work is performed on an update or delete, such as firing triggers, enforcing constraints etc?

"NOTE: Own changes means changes made by the result set itself, while other changes means changes made by other transactions of other objects in the same transaction. " _  I think you mean 'other transactions OR other objects in the same transaction'

"In order to be able to view own changes, whenever the updateRow() method is called, the hashtable has to be updated with the new values for the updated columns" - how is this being implemented, couldn't see any mention of it.


> 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