db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
Date Wed, 17 Aug 2005 18:31:20 GMT
Philip Wilder (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
>
>Philip Wilder updated DERBY-213:
>--------------------------------
>
>    Attachment: Derby213patch_Aug112005.patch
>
>An interim patch to bring client in line with embedded. Includes the following changes:
>- Additional tests in jdbcapi/resultset.java
>  
>
I got a little lost in the tests, but generally more tests are good.  A
couple of thoughts..

Maybe your chart that explains the helper array could be expanded to
cover what is being tested or else have comments in the code or test
output that makes it clear.

I don't think it is  so good to have  references to internal classes
(e.g org.apache.derby.client.am.ResultSet) in the functional tests.
Is there a  way within the public API to test if autocommit has
occurred, maybe the current XID from the lock table VTI would help.

It seemed a  little funny to have the tablename as a static particularly
at the bottom of the file.

The DerbyNet canon says FAIL and prints an exception for one test.  I
think in fact the behavior is different for the driver, so I would think
it better to either skip the test or print it in the master as expected
output for that framework.


>- Change to special flag to fix a small NullPointerException
>  
>
OK

>- modified output files for resultset.out, updatableResultSet.out, holdCursorJDBC30, forupdate.out
>- Changes to ResultSet, Statement and Connection in the org.apache.derby.client.am package.
These changes have the following effects: 
>      * FORWARD_ONLY ResultSets will no longer close implicitly after the last ResultSet
has been retrieved. 
>  
>
It looks like FORWARD_ONLY ResultSets will no longer close implicitly
after the last *row*  has been retrieved and that looks ok.

>      * Checks to see if an auto-commit should be performed have been moved to Statement
to mimic embedded functionality.
>      * Multiple ResultSets will now auto-commit if all ResultSets are closed if auto-commit
is turned on.
>
>  
>
Statement.java has an import of  
org.apache.derby.impl.jdbc.EmbedResultSet which it should not. I don't
think it is being used.


This is my *big* question about the code changes.  It looks like the
autocommit will only be sent if the result sets are actually closed  not
if I fetch past the last row of a forward only result set as I think is
supposed to be the case.  Am I reading this correctly?


>While the derbyall test suite was run with only one failure (since rectified), there are
still a couple of issues worthy of consideration.
>- Connection.setAutoCommit() java documentation states " In advanced cases, a single statement
may return multiple results as well as output parameter values. In these cases, the commit
occurs when all results and output parameter values have been retrieved." While my solution
auto-commits when all ResultSets have been closed, it does not take into consideration output
parameters. However, looking at the embedded implementation it does not look like embedded
takes output parameters into consideration either.
>- The SVN patch tool seems to act very strangely for updatableResultSet.out, deleting
then adding lines that were identical. I cannot account for this behavior.
>  
>
did reverting,  updating  the eol properties correct this problem?


>- CallableStatements are a new addition to the resultset.java test class. I felt it was
an appropriate addition because I was still testing ResultSets (albeit multiple ResultSets)
but I'm open to alternate suggestions.
>  
>
>- The changes to jdbcapi/resultset.java are not particularly compatible with java 1.3.X
as I make reference to change ResultSet holdability in multiple places. This did not appear
to cause any problems but it is something to be aware of. 
>
>  
>
You used reflection so the test should work fine with jdk131.



Mime
View raw message