Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 83636 invoked from network); 1 Mar 2006 16:40:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Mar 2006 16:40:16 -0000 Received: (qmail 79192 invoked by uid 500); 1 Mar 2006 16:40:55 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 79124 invoked by uid 500); 1 Mar 2006 16:40:54 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 79114 invoked by uid 99); 1 Mar 2006 16:40:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Mar 2006 08:40:54 -0800 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [192.18.98.34] (HELO brmea-mail-3.sun.com) (192.18.98.34) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Mar 2006 08:40:53 -0800 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k21GeXQj003605 for ; Wed, 1 Mar 2006 09:40:33 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IVG00701JFF5U00@mail-amer.sun.com> (original mail from Lance.Andersen@Sun.COM) for derby-dev@db.apache.org; Wed, 01 Mar 2006 09:40:33 -0700 (MST) Received: from [129.150.64.170] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IVG00A2IJNJ9W50@mail-amer.sun.com> for derby-dev@db.apache.org; Wed, 01 Mar 2006 09:40:33 -0700 (MST) Date: Wed, 01 Mar 2006 11:40:36 -0500 From: "Lance J. Andersen" Subject: Re: [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets In-reply-to: <810958483.1141222157048.JavaMail.jira@ajax.apache.org> Sender: Lance.Andersen@Sun.COM To: derby-dev@db.apache.org Message-id: <4405CE84.7090201@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_uJyWFyAgKTQgu0hB2+BdfQ)" References: <810958483.1141222157048.JavaMail.jira@ajax.apache.org> User-Agent: Thunderbird 1.5 (Windows/20051201) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --Boundary_(ID_uJyWFyAgKTQgu0hB2+BdfQ) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT The wording in chapter 14 of JDBC 3 in sections 14.2.4.1 Updating a Row, 14.2.4.2 Deleting a Row, 14.2.4.3 Inserting a Row The wording was carried unmodified forward to JDBC 4 Andreas Korneliussen (JIRA) wrote: > [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12368286 ] > > Andreas Korneliussen commented on DERBY-690: > -------------------------------------------- > > I found the following in the JDBC 2.1 spec: > " > 5.8.3 A result set s own changes We have pointed out that the visibility of changes made by others generally depends on a result set s type. A final point that concerns the visibility of changes via an open result set is whether a result set can see its own changes (inserts, updates, and deletes). A JDBC technology application can determine if the changes made by a result set are vis-ible to the result set itself by calling the DatabaseMetaData methods: ownUpdate-sAreVisible, ownDeletesAreVisible, and ownInsertsAreVisible. These methods are needed since this capability can vary between DBMSs and JDBC drivers. One s own updates are visible if an updated column value can be retrieved by calling getXXX() following a call to updateXXX(). > " > > So the visibility of the ResultSets own changes does not have anything to do with the value in the database, it is the values you set when calling updateXXX(). (The values do not go down to the database until updateRow() is called). > > Has this been changed in JDBC 3 and later ? > > >> 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. >> > > --Boundary_(ID_uJyWFyAgKTQgu0hB2+BdfQ) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT The wording in chapter 14 of JDBC 3 in sections 14.2.4.1 Updating a Row, 14.2.4.2 Deleting a Row, 14.2.4.3 Inserting a Row

The wording was carried unmodified forward to JDBC 4



Andreas Korneliussen (JIRA) wrote:
    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12368286 ] 

Andreas Korneliussen commented on DERBY-690:
--------------------------------------------

I found the following in the JDBC 2.1 spec:
"
5.8.3 A result set s own changes We have pointed out that the visibility of changes made by others generally depends on a result set s type. A final point that concerns the visibility of changes via an open result set is whether a result set can see its own changes (inserts, updates, and deletes). A JDBC technology application can determine if the changes made by a result set are vis-ible to the result set itself by calling the DatabaseMetaData methods: ownUpdate-sAreVisible, ownDeletesAreVisible, and ownInsertsAreVisible. These methods are needed since this capability can vary between DBMSs and JDBC drivers. One s own updates are visible if an updated column value can be retrieved by calling getXXX() following a call to updateXXX().
"

So the visibility of the ResultSets own changes does not have anything to do with the value in the database, it is the values you set when calling updateXXX().  (The values do not go down to the database until updateRow() is called).  

Has this been changed in JDBC 3 and later ?

  
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.
    

  
--Boundary_(ID_uJyWFyAgKTQgu0hB2+BdfQ)--