Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 45984 invoked from network); 27 May 2005 16:09:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 May 2005 16:09:32 -0000 Received: (qmail 84348 invoked by uid 500); 27 May 2005 16:09:30 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 84287 invoked by uid 500); 27 May 2005 16:09:30 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 84269 invoked by uid 99); 27 May 2005 16:09:30 -0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,SPF_HELO_FAIL X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from e2.ny.us.ibm.com (HELO e2.ny.us.ibm.com) (32.97.182.142) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 27 May 2005 09:09:24 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4RG9A4l020128 for ; Fri, 27 May 2005 12:09:10 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4RG95RS113124 for ; Fri, 27 May 2005 12:09:09 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4RG8tff002134 for ; Fri, 27 May 2005 12:08:55 -0400 Received: from [127.0.0.1] (MARSDEN-IBM-LT1.usca.ibm.com [9.72.133.53]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4RG8qW3001829 for ; Fri, 27 May 2005 12:08:55 -0400 Message-ID: <4297460A.80909@sbcglobal.net> Date: Fri, 27 May 2005 09:08:42 -0700 From: Kathey Marsden User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derby Development Subject: DERBY-213 IRC chat X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------060703030004070703050008" X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --------------060703030004070703050008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This morning there was an IRC chat regarding DERBY-213. Attending kmarsden (Kathey - California) Bogomip_ (Phillip - New York) bernt (Bernt - Norway) Context Phillip and I are working on DERBY-213 using a virtual incarnation of the pair programming practices of Extreme programming outlined at http://en.wikipedia.org/wiki/Pair_programming. This means we make our tests first and work closely together towards a solution. Makes for chatty IRC. The Chat The full transcript is attached for those wishing to drill deeper. We talked about a general strategy for fixing this bug and took the steps outlined below. 1) Confirm this a bug. Looking at the javadoc for ResultSet we agreed that this looks like a bug. We should not close the result set if we fetch past the last row. 2) Get a stand alone repro Phillip agreed to work on this. He will make a repro program that we can run for all frameworks. e.g. derby213 [derby|derbynet|derbynetclient] Phillip will post to the list so that others can use it when fixing bugs to check all frameworks. 3) Add the test case to an existing test We talked about how it is better to add our case to an existing test than create a new one. We looked at the testing framework, the different directories store,jdbcapi, etc under functionTests/tests and also at the suites and looked at how to figure out if a test runs under network server. We decided we would add our case to jdbcapi/resultset.java and noted the *three* masters that we will have to update when we change the test. 4) Check the embedded behaviour. 5) Think of other related cases we want to test Phillip will think about that. 6) Add those to the test. 7) Start thinking of how to fix Phillip will work on the repro and we will meet again 5am PST on Tuesday, May 31. Thanks Kathey --------------060703030004070703050008 Content-Type: text/plain; name="DERBY-213_irc_5_26_2005" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="DERBY-213_irc_5_26_2005" [04:58] *** now talking in #derby [04:58] *** topic is Apache Derby [04:58] *** set by jboynes on Thu May 19 09:35:04 2005 [04:58] *** channel #derby mode is +n [04:58] *** channel created at Thu May 19 09:34:51 2005 [04:59] Connection trouble? [05:00] xChat was acting strange. I couldn't access any of the menus. [05:00] Anyway, I'll deal with that later [05:00] alright. So what's first? [05:00] OK. So first let's look at the bug. What bug is this ? [05:01] 213 I believe [05:01] "ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server" [05:01] It is always important first to look closely at the bug and just evaluate whether or not it really is a bug. [05:02] Anyone can put anything they want in Jira [05:02] just slow internet in general this morning [05:02] :-( [05:03] OK. So we should double check the javadoc for ResultSet.next() to make sure this is true. [05:03] that next() should continue to return false past the end of the ResultSet [05:04] I am not sure what resources you have used in terms of specs [05:04] theres the javadoc [05:04] http://java.sun.com/j2se/1.4.2/docs/api/index.html [05:05] the JDBC specs at the sun site [05:05] looking at it now. [05:05] You are right, it makes no mention of SQLexceptions in conjuction with an implicitly closed database [05:06] simply says, "false if there are no more rows" [05:07] So the assertion that is made by the bug is: [05:07] Calling next() past the end of a forward only ResultSet should not close the ResultSet. [05:08] javadoc says [05:08] calling next() will return true if the new current row is valid; false if there are no more rows [05:09] The only time an Exception is specified is on a database error. [05:09] Also no methion is made about any sort of implicit closing in the class declaration. [05:09] right. So I think the bug is right. [05:09] do you? [05:10] Hi! [05:10] Morning bernt [05:10] hi Bernt. Are we too chatty for you? [05:10] I think this is a genuine bug (btw: its 14:10 here ;-) [05:10] me too [05:10] Oh you crazy other side of the world fol. [05:10] *folk [05:11] Phillip do you concur that this is a bug? [05:11] I believe I do. [05:11] excellent. [05:11] Another intersing point here is that there is no metioning in the specs on what next() should do when on the insertRow [05:11] (At least, I can't find it) [05:12] I don't know if I am clear on what you are saying [05:13] I think bernt is talking about another issue. [05:13] Which itself may be potentially problematic but not strictly related with what we are doing here. [05:14] ok. So the next step is to check embedded behaviour and put the case into a test so we know when we are done. [05:14] Ok. ANother time (but it's somewhat related) [05:15] can you explain? [05:15] if it will affect what we are doing here we should consider it. [05:16] Probably not. It's related to updatable resultsets. [05:16] ok. So we should state what we are doing here in terms of behaviour. [05:17] We are changing network server/client to not close the resultset when next() is called past the last row of a forward only ResultSet. [05:17] next will always return false in this case. [05:17] correct? [05:17] agreed. [05:17] agree. [05:18] Ok. Was there a java repro attached to the bug or just a code snippet? [05:18] Sorry, repro? [05:18] reproduceable case. a java program that shows the trouble. [05:19] vs. a Code snippet which... [05:19] is a cut and paste into the jira entry. [05:19] I guess both are repros [05:19] one is ready to run the other makes you do work [05:19] Check :-) [05:20] Unless I am reading Jira incorrectly, it just looks like a snippet. [05:21] hmmm.... I believe this code snippet would involve modifying an existing database or creating a new one. [05:21] by Extreme programming standards you always make your test first so you know when you are done. [05:21] this is good but actually makes it hard for debugging [05:21] so I usually do both. [05:22] I find a test and add the case to that and I make a small standalone program that I can use to fix it. [05:23] In terms of making tests, are you talking about adding a test to a test suite? [05:23] For a bug like this we don't want to add a new test. [05:23] as in a new java program [05:23] we just want to find something like resultset.java and add this case into it. [05:24] Ok, when talking about derby there are a number of resultsets to consider which one do you mean in this context? [05:25] you mean a number of resultset tests? [05:25] Both I guess :-) [05:25] I'm just thinking of iapi.ResultSet, java.sql.ResultSet, impl.jdbc.EmbeddedResultSet, etc. [05:26] oh. [05:26] I am just thinking right now about a test where we can add our test case for this bug. [05:26] We won't go to any of those classes for this one. [05:26] K [05:26] since it is a network server issue [05:27] In general our strategy is [05:27] 1) confirm this a bug. done [05:27] 2) Get a stand alone repro [05:27] 3) Add the test case to an existing test [05:28] 4) Check the embedded behaviour. [05:28] 5) Think of other related cases we want to test [05:28] 6) Add those to the test. [05:29] 7) Start thinking of how to fix [05:29] sould ok [05:29] ? [05:29] s/sould/sound [05:30] Sounds alright to me. [05:30] I'm sure you will outline where these tests will be placed presently. [05:30] Yes. [05:30] Can you start making our stand alone repro while I go look for a good place to hang this test [05:31] ? [05:31] Alright, shall I use the snippet from the jira entry? [05:31] sure. That's good. [05:33] Alright I'm envisioning 3 java classes. One to create the appropriate database, another to run a network server and the third to act as a client to the server using the code snippet. [05:34] I might be able to bundle all of this together but I think that would intermix the output of the server and the client. [05:35] Well for the standalone repro we will start the server manually. [05:35] k [05:35] the standalone repro is sort of a throw away thing [05:35] Since the tests will be updated to include the case. [05:36] I have a template that I use. but messy. Let me look at it [05:36] Sure. [05:38] For my repros I usually have a parameter for the connection type, for instance. [05:39] derby213 derby [05:39] derby213 derybnetclient [05:40] This is passed as a commandline argument and is used to determine if the client will connect locally or via DRDA? [05:40] Right. I actually have about 11 different connection types in this thing so it is all to messy to send you. [05:41] but here are bits [05:41] public static Connection initConn(String conntype, String dbname) throws Exception ... [05:41] else if (conntype.equals("derby")) [05:41] { [05:41] driver = "org.apache.derby.jdbc.EmbeddedDriver"; [05:41] url = "jdbc:derby:" + dbname + ";create=true"; [05:41] } [05:41] else if (conntype.equals("derbynet")) [05:41] { [05:41] driver = "com.ibm.db2.jcc.DB2Driver"; [05:41] url = "jdbc:derby:net://localhost:1527/" + dbname +";create=true:retrieveMessagesFromServerOnGetMessage=true;"; [05:41] } [05:41] that is bad in IRc [05:42] I'm getting smileys on my side :-) [05:42] I think I get the idea though. [05:42] In this case will we only worry about the two connection types? [05:43] three derbynet, derbynetclient and derby. [05:43] else if (conntype.equals("derbynetclient")) [05:43] { [05:43] driver = "org.apache.derby.jdbc.ClientDriver"; [05:43] url = "jdbc:derby://localhost:1527/" + dbname + ";create=true"; [05:43] } [05:44] check [05:45] anyway you can reuse your Database class and this can be a connect method that returns a Connection or something like that. [05:46] ok. I will go look for a place for this tet [05:46] test [05:46] k, I'll try to have something for you asap. [05:50] Phillip, maybe it would be useful for uso go through this excercise of finding a test to add our case to together. [05:50] since we just have a few more minutes this morning [05:51] ok? [05:52] Sure. [05:52] Would you like me to email the testcase to the list after I am done with it? [05:52] That would be great. Do you want to do the summary, or should I do that? [05:54] You can do this one, then I'll know for next time what is considered to be the important material from a session like this. [05:54] Sounds good [05:54] OK. The tests [05:54] So the tests are under java/testing/derbyTesting/functionTests/ [05:55] there is a tests directory that has subdirectories for different test categories [05:55] like store, lang, derbynet (network server), lang (SQL), jdbcapi etc. [05:55] tests are either .sql tests (run with ij) [05:56] or .java tets [05:56] Under functionTests/suites there are a bunch of tests suites. [05:56] they do not have a 1-1 correspondence with the directories necessarily [05:57] For network server there are two relevant suites [05:57] derbynetmats and derbynetclientmats [05:57] I see them. [05:57] derbynetclientmats is for the new client. derbynetmats is for the DB2 Universal JDBC Driver [05:58] Let's look at derbynetclientmats [05:58] the properties file shows the suites that will run for this suite [05:59] so in derbynetclientmats.properties we see the subsuites that are run are derbynetmats and it also has to list itself to pick up the tests in the derbynetclientmats.runall file [06:00] this is just a quirky harness thng [06:00] Alright. [06:00] in addition to the derbynetclienmats.properties file there is a derbynetclientmats.runall file [06:01] this one shows a few individual tests that run for client [06:01] *** bernt quit ("leaving" ) [06:02] Neither of which appear particularly relevant to our current project. [06:03] right. Just wanted to show how the thing was structured. [06:03] By the way if you have other obligations we can finish this later. [06:03] So we want to change something related to ResultSet [06:03] I can go just a few more minutes [06:03] if you want to [06:04] I have time. [06:04] ResultSet tests would be under jdbcapi [06:04] I thought jdbcapi/resultset.java [06:05] To check that this runs with network server you would need to trace the suite. [06:06] I usually grep for which suite it is in [06:06] $ grep resultset.java *.runall [06:06] jdbcapi.runall:jdbcapi/resultset.java [06:07] then grep for that suite in the properties files [06:07] grep jdbcapi *.properties [06:08] I'm actually using eclipse as my development environment, in combination with dos commandline. [06:08] Unfortunately that leaves me with a lack of grep. [06:08] #:) [06:09] nevertheless, I can probably use a poor mans search tool to the same effect [06:09] But anyway the jdbcpi suite does run for network server [06:10] Another easy indicator that this test is run for network server is the fact that it has a separate master [06:10] under the master directory we have [06:10] ./resultset.out [06:10] ./DerbyNet/resultset.out [06:10] ./DerbyNetClient/resultset.out [06:10] that tells us when whe change this test we will probably have to update three masters [06:11] Anyway resultset.java is propbably the place to put this. [06:11] So until next time. [06:12] Aright, thank you for your time. [06:12] When would you like next time to be? [06:12] 1) You will work on the repro. 2) I will post a summary to the list. [06:12] Well, how about Tuesday morning? [06:13] Sure, that would be great. [06:13] Same time and duration? [06:13] yes [06:13] Extra credit is add our test case to resulset.java and think of other cases we should test [06:14] It should pass for embedded [06:14] Indeed. [06:15] ok. bye for now [06:15] Talk to you tuesday. [06:17] *** bernt (~Bernt@159.80-202-210.nextgentel.com) joined [06:17] thanks for your patience Bernt. We're done until Tuesday morning. [06:18] No problem. --------------060703030004070703050008--