db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "?ystein Gr?vlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Fri, 17 Mar 2006 10:12:01 GMT
    [ http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12370799 ] 

Øystein Grøvlen commented on DERBY-690:

Here are my review comments to the JDBC changes.  Generally, there are
also in this part of the code several Javdoc-@param without parameter

17. EmbedResultSet

17.1 rowUpdated()/rowDeleted()

     a) Why is checkIfClosed removed?

17.2 addWarning()

     a) I would like javadoc for this method

18. EmbedDatabaseMetaData

18.1 othersUpdatesAreVisible()

     a) The added comment was placed a bit strange. Since it supposed
        to cover all three methods, either put it above the Javadoc
        for the first method, or duplicate withing Javadoc for all.

19. EmbedConnection

19.1 setResultSetConncurrency()

     a) Is there any point in keeping this method around?  It just
        returns one of it input parameters.

20. Added SqlState

    a) Is it necessary to prefix the message with "WARNING:"?  I would
       think that would be possible to determined from the context.
       If kept, capitalize after colon.

    b) According to the ODBC guide I have access to, this SqlState is
       for "A positioned UPDATE or a positioned DELETE SQL statement
       was specified, and no row or more than one row was updated or
       deleted."  As far as I can tell, you will also use this warning
       when one reposition to a deleted row.  Is that according to the

    c) For the text of this message you have used the "subcondition"
       specified in the SQL spec.  Is that a requirement?  I thought
       the spec only put a requirement on the state and not the
       associated text.  I think something more descriptive, like what
       I found in the ODBC guide would be helpful to users.

> 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, derby-690-v4.diff, derby-690-v4.stat, derby-690-v5.diff, derby-690-v5.stat,
sur-proposal.txt, writeup-v1.html, writeup-v2.html, writeup-v3.html, writeup-v4.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