Hi, >>>>> "KM" == Kathey Marsden <[EMAIL PROTECTED]> wrote:
KM> Attached are the transcripts from the chat. Next meeting is Thursday, KM> June 2, 9am PST . KM> If you made it this far, I am looking for input on summaries for IRC chats.. KM> KM> * Is this too much / too little detail. KM> * Are the transcripts at all helpful? I think I might drop them if KM> they are not useful. I, for one, like this approach (IRC) and format (your summary). The summary let's me decide if I want to read the rest. Reading the dialogue provides pointers for understanding Derby better. It's like listening in on hallway conversations in real life; useful for catching stuff one would otherwise miss, including understanding how others work in practice. As for volume (weekly or per chat), I am fine with either. Thanks! Dag KM> * Would a weekly summary be better? KM> KM> Thanks KM> KM> Kathey KM> KM> kmarsden good morning Philip KM> Bogomips_ Morning KM> kmarsden how are your tests? KM> Bogomips_ Much more promising KM> Bogomips_ Total of 594 tests, 92 of which fail. For what looks like legitimate reasons. KM> Bogomips_ This is for derbyAll KM> kmarsden What fails? KM> Bogomips_ Many of the dml tests that were running before as well as the netmat tests. KM> Bogomips_ However this was before I new of removing the trace, so you might be able to cut down on those failures as well. KM> kmarsden did you see my note about not using ij.exceptionTrace=true KM> kmarsden ok KM> Bogomips_ :-) KM> kmarsden What fails in derbynetmats KM> kmarsden ? KM> Bogomips_ derbyall/derbynetclientmats/derbynetclientmats.fail:derbynet/netxaPositive.sql KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/NSinSameJVM.java KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/badConnection.java KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/callable.java KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/checkSecMgr.java KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/csPrepStmt.java KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/dblook_test_net.java KM> Bogomips_ derbyall/derbynetclientmats/derbynetmats.fail:derbynet/dataSourcePermissions_net.java KM> Bogomips_ among others. KM> kmarsden do you know why yet? KM> kmarsden oh this is probably because you do not have db2jcc.jar and db2jcc_license_c.jar KM> kmarsden in your classpath KM> Bogomips_ Some of them complain about a lack of master file. Another has a security exception. KM> kmarsden hmmm KM> kmarsden derbynetclientmats is ok? KM> Bogomips_ There were a lot of netclient problems, but I'm looking at the tests prior to removing your the trace. KM> Bogomips_ Shall I try removing the trace for just the singular resultset test? KM> kmarsden The trace I am quite sure does not affect the network server tests. I run those just about every day KM> kmarsden It had been a while since I had run derbyAll so that is why I hit the nist thing. KM> kmarsden But yes, let's work on resultset.java and then you can look at your test failures later today. KM> kmarsden and ping me if you have questions. KM> kmarsden Does that sound ok? KM> Bogomips_ Sure, sounds good. KM> kmarsden ok. first we run resultset.java for embedded KM> Bogomips_ k KM> kmarsden oh I have an outdated copy. Is the one you mailed me the latest. KM> Bogomips_ ? KM> Bogomips_ This is from the second email I sent you? KM> kmarsden there was a mail delay. I have the one from Jira but I will look for your mail now KM> Bogomips_ Ok, should be titled "Derby-213 files May 31, 10:00 a.m. AST" KM> kmarsden 5:46 am yesterday. Is that right? KM> kmarsden no 6:07 KM> Bogomips_ Ya, that would be the time on it. KM> kmarsden Attempt to shutdown framework: DerbyNetClient KM> kmarsden 1a2,8 KM> kmarsden > Begin ImplicitClose tests KM> kmarsden > 1 KM> kmarsden > 2 KM> kmarsden > Final call to ResultSet.next() KM> kmarsden > Call to ResultSet.next() thows the following exception: KM> kmarsden > org.apache.derby.client.am.SqlException: Invalid operation: result set closed KM> kmarsden > ImplicitClose tests complete KM> kmarsden Test Failed. KM> kmarsden *** End: resultset jdk1.4.2_03 DerbyNetClient 2005-06-01 05:17:10 *** KM> kmarsden that's the output for client KM> Bogomips_ Sigh... KM> kmarsden that is good KM> kmarsden accidentally ran client first KM> Bogomips_ ok, good. Whew :-) KM> kmarsden *** Start: resultset jdk1.4.2_03 2005-06-01 05:18:21 *** KM> kmarsden 1a2,7 KM> kmarsden > Begin ImplicitClose tests KM> kmarsden > 1 KM> kmarsden > 2 KM> kmarsden > Final call to ResultSet.next() KM> kmarsden > Call successful KM> kmarsden > ImplicitClose tests complete KM> kmarsden Test Failed. KM> kmarsden and for embedded KM> Bogomips_ good :-) KM> kmarsden For embedded looks good except it says it failed KM> Bogomips_ well, you still have to run ant, correct? KM> Bogomips_ for the new master file. KM> kmarsden but I think we just need to update the master KM> Bogomips_ agreed KM> kmarsden do you get the same result KM> kmarsden ? KM> Bogomips_ Before I modified the master, yes. KM> kmarsden so now mine passes KM> kmarsden OK. So lets look a bit at qryclsimp KM> kmarsden First looking at the specs KM> kmarsden http://www.opengroup.org/dbiop/ KM> kmarsden There are three specifications. KM> kmarsden DRDA - Describes the overall flow KM> kmarsden FD:OCA describes the data type translation for different machines KM> kmarsden DDM describes the tokens that we send back and forth KM> kmarsden That is the 10,000 foot overview KM> kmarsden We are going to look at the DDM Manual C045 KM> Bogomips_ Now to enter the orbit? KM> Bogomips_ k KM> kmarsden if you search for qryclsimp KM> kmarsden You will see I think that is only sent as part of the OPNQRY request. KM> Bogomips_ Alright KM> kmarsden looking at page 680 you can see the various values that can be sent KM> kmarsden 00 - Server choice KM> Bogomips_ 694 volume 3 KM> kmarsden right. KM> kmarsden I think I gave you the page number at the bottom. KM> kmarsden 01 - Server has to close KM> kmarsden 02 - Server should not close KM> kmarsden the server should ignore the request for scrollable cursors even if 01 KM> kmarsden The server indicates the end of data with SQLState 0200 KM> kmarsden sorry 02000 KM> kmarsden Do you see any more useful information here? KM> Bogomips_ looking KM> Bogomips_ If the query is scrollable, the server ignores the QRYCLSIMP value. KM> Bogomips_ There is also the definition of implicit closing but that is easily understood. KM> kmarsden yes. So I think that what this tells us is that we need to add a test for a scrollable cursor fetching past the end. KM> kmarsden to make sure it doesn't get closed KM> Bogomips_ Alright. Now to find out how to request a scrollable ResultSet KM> kmarsden http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Connection.html#prepareStatement(java.lang.String, int, int) KM> Bogomips_ I believe the javadocs for java.sql.Connection.createStatement(int resultSetType, int resultSetConcurrency) tell us. KM> Bogomips_ also true. KM> kmarsden I am guessing there are examples in resultset.java KM> Bogomips_ quite possibly. KM> kmarsden looking KM> Bogomips_ There is an example with SCROLL_INSENSITIVE, but I cannot find the reverse. KM> kmarsden I think that would be fine for this. KM> kmarsden but we will look at the code and see if there is any special handling for SCROLL_SENSITIVE and decide if we need two tests KM> kmarsden For now we can just make a note to add a test while we finish our analysis KM> kmarsden I put todo tags in chats sometimes. KM> Bogomips_ Alright. KM> Bogomips_ Do you know which of these two options statements default to? KM> kmarsden TODO: Write tests fetching past end of scrollable resulsets. KM> kmarsden hmm. KM> Bogomips_ "Result sets created using the returned Statement object will by default be type TYPE_FORWARD_ONLY and have a concurrency level of CONCUR_READ_ONLY." KM> kmarsden Resultsets default to forward only KM> kmarsden Then you specifify SCROLL_SENSITIVE or SCROLL_INSENSITIVE explicitly if you want scrollable. KM> kmarsden TYPE_SCROLL_INSENSITIVE KM> kmarsden - The constant indicating the type for a ResultSet object that is scrollable but generally not sensitive to changes made by others. KM> kmarsden TYPE_SCROLL_SENSITIVE KM> kmarsden - The constant indicating the type for a ResultSet object that is scrollable and generally sensitive to changes made by others. KM> kmarsden OK. So you said you think the client sends 01? KM> Bogomips_ On further analysis, I believe the DerbyNet framework sends 01 and the DerbyNetClient sends 00. KM> kmarsden OK. good. Then probably what is going to happen with our resultset.java test is that derbynet is going to keep its current output. KM> kmarsden Only derbynetclient will change behaviour since it sends SERVER_CHOICE (00) KM> kmarsden Our changes will be on the server side. KM> kmarsden Let's look at DRDAStatement.java KM> Bogomips_ Understood. Beyond petitioning IBM for changes in the db2jcc.jar there is little we can do for a value of 01. KM> Bogomips_ You may wish to verify my findings. KM> kmarsden We will verify. I figure we will change the SERVER_CHOICE option and see what the behaviour is #:) KM> kmarsden As for petitioning IBM, I guess you could petition me since I work for IBM. KM> kmarsden I will file a bug with JCC and hopefully they will fix. KM> kmarsden but we will just worry about the server and client for our changes. KM> Bogomips_ :-) KM> Bogomips_ Of importance before we start modifying codepoint values is the small bug in the setOPNQRYoptions(). KM> kmarsden yes KM> kmarsden The one thing that strikes me in looking at this is that QRYCLSIMP is only sent on OPNQRY KM> kmarsden not on PRPSQLSTT or any other statement related call. KM> kmarsden I think that it is wrong that it is in DRDAStatement at all KM> kmarsden If we look at setOPNQRYoptions it is just updating the DRDAResultSet values. KM> kmarsden and if we fix the bug you found. the value in DRDAStatement is not being used at all I think. KM> Bogomips_ Quite possibly. KM> kmarsden If i check references for DRDAStatement.qryclsimp KM> kmarsden it is only used by setOPNQRYoptions, but in fact shouldn't be used there at all. KM> Bogomips_ It is a protected variable so it can be called from other classes in the package. Is it there for future compatibility? KM> kmarsden I don't think so. KM> Bogomips_ Or should the value always be specific to the DRDAResultSet? KM> Bogomips_ k KM> kmarsden It should always be specific to the resultset. KM> kmarsden I think it is just part of the general messiness of network server. KM> Bogomips_ Alright. A subsequent issue that might stem from our investigations would be to clean up DRDAStatement. KM> kmarsden I think the same will apply to the other options as well. KM> kmarsden Yes! KM> Bogomips_ Alright. KM> Bogomips_ I guess we are out of time, do you have any homework assignments for me :-) KM> kmarsden Yes. Search the rest of the DDM Manual and DRDA manual for qryclsimp references and make sure we are not missing anything KM> kmarsden Think about adding a test for scrollable resultsets to our test. KM> kmarsden get your tests running KM> kmarsden I guess that last one is the most important. KM> Bogomips_ Indeed. KM> Bogomips_ Do you think we need to test ResultSets from both PreparedStatements and Statements? If not I can remove that functionality and replace it with Scrollability. KM> Bogomips_ If we do need both statements, I'll just layer the additional functionality on top. KM> kmarsden I think that we don't need both prepared statements and statements since they wil both go through the same code path KM> Bogomips_ k KM> kmarsden The general idea is that our tests optimally will provide 100% code coverage of the areas we change. KM> Bogomips_ Since this is an area we will likely not touch it will not be needed. KM> Bogomips_ Alright, when would you next like to meet? KM> kmarsden Hold on. let me check something KM> kmarsden if we meet 9am my time tomorrow is that too late for you? KM> Bogomips_ No that should be fine. KM> kmarsden OK. good. until then. KM> Bogomips_ bye KM> * Bogomips_ ([EMAIL PROTECTED]) has left #derby KM> -- Dag H. Wanvik Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43496/+47 73842196, Fax: +47 73842101 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
