[ 
https://issues.apache.org/jira/browse/DERBY-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kim Haase updated DERBY-3668:
-----------------------------

    Attachment: DERBY-3668-3.zip
                DERBY-3668-3.diff

Thanks again, Dag, for the great comments. I have done some more work on that 
one topic ("Using auto-commit, cdevconcepts29416.dita) and attached 
DERBY-3668-3.diff and DERBY-3668-3.zip with more changes. A few specific 
questions/comments:

"The last sentence seems pointless. It is probably intended for the entry 
"Updatable cursors" and "Auto-commit off". Since JDBC has updatable ResultSets, 
explicit cursors are not really needed."

So would it make sense to move "Not required by the JDBC program" to the 
"Updatable cursors" row of the table? Or just to drop it entirely? It doesn't 
seem like very helpful information. I've dropped it -- let me know if it should 
be added to the other row.

Thanks for the info about nested savepoints. I will keep an eye on DERBY-3687.

I have changed "A cursor declared to be held across commit" to "An updatable 
cursor declared to be held across commit".

And I have changed

"A holdable forward-only cursor must be repositioned before any statement 
following the commit."

to

"A holdable forward-only cursor must be repositioned before the close or next 
method call that follows the commit."

I hope that works?

I was also confused by the references to the "close cursors on commit option", 
because that seemed like odd terminology for JDBC. It appears to refer to 
specifying ResultSet.CLOSE_CURSORS_AT_COMMIT as the third argument 
(resultSetHoldability) in a Connection.createStatement, Connection.prepareCall, 
or Connection.prepareStatement method call. I've tidied up this language a 
little. I also mention that ResultSet.HOLD_CURSORS_OVER_COMMIT is the default 
value (this is stated in the Reference Manual topic on the 
java.sql.DatabaseMetaData interface). I hope this is all correct.

I will file a JIRA for documenting the SAVEPOINT, RELEASE, COMMIT, and ROLLBACK 
statements. Then perhaps we can get some discussion about whether this is a 
good idea.

> Remove JDBC 3.0-specific topics from Reference Manual and merge 
> implementation notes as needed
> ----------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3668
>                 URL: https://issues.apache.org/jira/browse/DERBY-3668
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Documentation
>    Affects Versions: 10.4.1.3
>            Reporter: Kim Haase
>            Assignee: Kim Haase
>            Priority: Minor
>         Attachments: DERBY-3668-2.diff, DERBY-3668-2.stat, DERBY-3668-2.zip, 
> DERBY-3668-3.diff, DERBY-3668-3.zip, DERBY-3668.diff, DERBY-3668.stat, 
> DERBY-3668.zip
>
>
> The following files should be removed and their contents merged, where 
> appropriate, with the main files for the interfaces concerned. If 
> implementation notes in the JDBC 3.0 topics are identical to the javadoc 
> (i.e. they are not really implementation notes), they can be dropped.
> rrefjdbc32593.html ("JDBC 3.0 features"): remove.
> rrefjdbcjavasqlconnection30.html ("java.sql.Connection interface: supported 
> JDBC 3.0 methods"): remove and merge implementation notes with 
> rrefjdbc27734.html ("java.sql.Connection interface") as needed. Only the last 
> two items in the table contain implementation-specific information.
> rrefjdbcdatabasemetadata30.html ("java.sql.DatabaseMetaData interface: 
> supported JDBC 3.0 methods"): remove and merge implementation notes with 
> rrefjdbc15905.html ("java.sql.DatabaseMetaData interface") as needed. Only 
> the last item in the table contains implementation-specific information.
> rrefjdbcparametermetadata30.html ("java.sql.ParameterMetaData interface: 
> supported JDBC 3.0 methods"): remove. No need to create a topic for this 
> interface in the general JDBC reference, since there is no 
> implementation-specific information for it.
> rrefjdbcjavasqlpreparedstatement30.html ("java.sql.PreparedStatement 
> interface: supported JDBC 3.0 methods"): remove. No implementation-specific 
> information to merge.
> rrefjdbcjavasqlsavepoint.html ("java.sql.Savepoint interface") and its 
> subtopics: This is a somewhat complicated case. There is information in here 
> that really belongs in the Developer's Guide, I believe. I think this topic 
> file should be moved up to the main JDBC reference section, but its only 
> contents should be the two Derby-specific restrictions described in 
> rrefjavsaverestrict.html ("Restrictions on savepoints"). The topic 
> rrefjavsaverestrict.html should then be removed, since the rest of its 
> contents are not implementation-specific. The substantive contents of 
> rrefjdbcjavasqlsavepoint.html ("java.sql.Savepoint interface"), 
> crefjavsavesetroll.html ("Setting and rolling back to a savepoint"), 
> crefjavsaverel.html ("Releasing a savepoint"), and crefjavsaverules.html 
> ("Rules for savepoints") could be combined into one topic and added to the 
> Developer's Guide, probably as an additional subtopic of "Transactions" under 
> "The JDBC Connection and Transaction Model", if that would make sense.
> rrefjdbcjavasqlstatement30.html ("java.sql.Statement interface: supported 
> JDBC 3.0 methods"): remove and merge implementation notes with 
> rrefjdbc40794.html ("java.sql.Statement interface") as needed. The subtopic 
> crefjavstateautogen.html ("Autogenerated keys") should be made a subtopic of 
> rrefjdbc40794.html ("java.sql.Statement interface"), after the "ResultSet 
> objects" topic.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to