db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: DerbyNetClient/lang/updatableResultSet fails
Date Thu, 02 Jun 2005 21:55:30 GMT
Cool. Thanks!

David Van Couvering wrote:

> Kathey already submitted a patch I made to fix this where I filter out
> the cursor name.  So this failure should no longer occur.
>
> David
>
> Satheesh Bandaram wrote:
>
>> I was trying to update some other master outputs, following
>> Tomohito's change. Looks like this got changed along with others. I
>> can either revert this or if it has already been done, then ok.
>>
>> Satheesh
>>
>> Mamta Satoor wrote:
>>
>>> Hi,
>>>  
>>> I am trying to understand the reasons behind updatableResultset test
>>> failure when using DerbyNetClient. Following is what I have found so
>>> far.
>>>  
>>> Satheesh made a checkin on May 25th (revision 178519) to the master
>>> file DerbyNetClient/updatableResultSet.out which was as follows
>>> +++
>>> incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/updatableResultSet.out
>>> Wed May 25 12:39:51 2005
>>> @@ -307,14 +307,14 @@
>>>  delete using first resultset
>>>  attempt to send deleteRow on the same row through a different
>>> resultset should throw an exception
>>>  SQL State : XCL08
>>> -Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
>>> +Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
>>>  Move to next row in the 2nd resultset and then delete using the
>>> second resultset
>>>  Positive Test11 - setting the fetch size to > 1 will be ignored by
>>> updatable resultset. Same as updatable cursors
>>>  Notice the Fetch Size in run time statistics output.
>>>  1
>>>  -----
>>>  Statement Name:
>>> -       SQL_CURLH000C54
>>> +       SQL_CURLH000C55
>>>  Statement Text:
>>>        SELECT * FROM t1 FOR UPDATE of c1
>>>  Parse Time: 0
>>>
>>> On May 26th, Bernt reported a diff which is reverse of master update
>>> done by Satheesh. Checkin from today (revision 179592) submitted by
>>> David seems to bring the master back to the state prior to
>>> Satheesh's checkin.   
>>> Also, Bernt, I looked at
>>> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
>>> <http://www.multinet.no/%7Esolberg/public/Apache/Derby/Limited/testSummary-178249.html>
>>> and the reason you didn't see the failure on Linux 2.4.19 and
>>> jdk1.4.2_08 I think is because the test never got run on that
>>> machine for some reason. In the list of tests that ran as part of
>>> derbynetclientmats on Linux 2.4.19 and jdk1.4.2_08, I don't see
>>> updatableResultset test in there. Let me know if I have missed
>>> anything. But if I am right, then we don't need
>>> updatableResultSet_sed.properties since we should get same cursor
>>> name irrespective of different platforms. The only question I have
>>> is why did Satheesh need to change the master? I am running with
>>> classes and maybe there is something that shows up only with the jar
>>> files. Satheesh, please let me know if there is an environment that
>>> I have not tested which required the master update.
>>>  
>>> thanks,
>>> Mamta
>>>  
>>>
>>> On 5/26/05, *Bernt M. Johnsen* <Bernt.Johnsen@sun.com
>>> <mailto:Bernt.Johnsen@sun.com>> wrote:
>>>
>>>
>>>     When running derbyall, DerbyNetClient/lang/updatableResultSet fails
>>>     the following way:
>>>
>>>     *** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient
>>>     2005-05-26 23:12:55 ***
>>>     Initialize for framework: DerbyNetClient
>>>     java -ms16777216 -mx33554432
>>>     -Dderby.system.home=/export/home/tmp/Derby/test/Der
>>>     byNetClient/updatableResultSet -Djava.security.manager
>>>     -Djava.security.policy=/e xport/home/tmp/Derby/test/nwsvr.policy
>>>     -Dcsinfo.codebase=/export/home/tmp/Derby/ trunk/jars/sane
>>>     -Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost org
>>>     .apache.derby.drda.NetworkServerControl start
>>>     Attempt to shutdown framework: DerbyNetClient
>>>     310 del
>>>     < Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
>>>     310a310
>>>     > Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
>>>     317 del
>>>     <       SQL_CURLH000C55
>>>     317a317
>>>     >       SQL_CURLH000C54
>>>     Test Failed.
>>>     *** End:   updatableResultSet jdk1.4.2_02 DerbyNetClient
>>>     2005-05-26 23:13:22 ***
>>>
>>>     (Same error with 1.5 and 1.3)
>>>
>>>     I'm running with Linux 2.6.11. What I find strange, is that when I
>>>     inspect the test failures in
>>>    
>>> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
>>>
>>>    
>>> <http://www.multinet.no/%7Esolberg/public/Apache/Derby/Limited/testSummary-178249.html>
>>>
>>>     I see that the same test fails in the same way on all platforms,
>>>     with the exception of the test run on a Linux 2.4.19 and
>>> jdk1.4.2_08
>>>
>>>     Comment anynone?
>>>     --
>>>     Bernt Marius Johnsen, Database Technology Group,
>>>     Sun Microsystems, Trondheim, Norway
>>>
>>>
>
>
>


Mime
View raw message