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
[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] <Bogomip_> Connection trouble?
[05:00] <kmarsden> xChat was acting strange. I couldn't access any of the menus.
[05:00] <kmarsden> Anyway, I'll deal with that later
[05:00] <Bogomip_> alright. So what's first?
[05:00] <kmarsden> OK. So first let's look at the bug. What bug is this ?
[05:01] <Bogomip_> 213 I believe
[05:01] <Bogomip_> "ResultSet.next() after last row of FORWARD_ONLY cursor
throws an SQL Exception with Network Server"
[05:01] <kmarsden> It is always important first to look closely at the bug and
just evaluate whether or not it really is a bug.
[05:02] <kmarsden> Anyone can put anything they want in Jira
[05:02] <kmarsden> just slow internet in general this morning
[05:02] <Bogomip_> :-(
[05:03] <kmarsden> OK. So we should double check the javadoc for
ResultSet.next() to make sure this is true.
[05:03] <kmarsden> that next() should continue to return false past the end of
the ResultSet
[05:04] <kmarsden> I am not sure what resources you have used in terms of specs
[05:04] <kmarsden> theres the javadoc
[05:04] <kmarsden> http://java.sun.com/j2se/1.4.2/docs/api/index.html
[05:05] <kmarsden> the JDBC specs at the sun site
[05:05] <Bogomip_> looking at it now.
[05:05] <Bogomip_> You are right, it makes no mention of SQLexceptions in
conjuction with an implicitly closed database
[05:06] <Bogomip_> simply says, "false if there are no more rows"
[05:07] <kmarsden> So the assertion that is made by the bug is:
[05:07] <kmarsden> Calling next() past the end of a forward only ResultSet
should not close the ResultSet.
[05:08] <kmarsden> javadoc says
[05:08] <kmarsden> calling next() will return true if the new current row is
valid; false if there are no more rows
[05:09] <Bogomip_> The only time an Exception is specified is on a database
error.
[05:09] <Bogomip_> Also no methion is made about any sort of implicit closing
in the class declaration.
[05:09] <kmarsden> right. So I think the bug is right.
[05:09] <kmarsden> do you?
[05:10] <bernt> Hi!
[05:10] <Bogomip_> Morning bernt
[05:10] <kmarsden> hi Bernt. Are we too chatty for you?
[05:10] <bernt> I think this is a genuine bug (btw: its 14:10 here ;-)
[05:10] <kmarsden> me too
[05:10] <Bogomip_> Oh you crazy other side of the world fol.
[05:10] <Bogomip_> *folk
[05:11] <kmarsden> Phillip do you concur that this is a bug?
[05:11] <Bogomip_> I believe I do.
[05:11] <kmarsden> excellent.
[05:11] <bernt> Another intersing point here is that there is no metioning in
the specs on what next() should do when on the insertRow
[05:11] <bernt> (At least, I can't find it)
[05:12] <kmarsden> I don't know if I am clear on what you are saying
[05:13] <Bogomip_> I think bernt is talking about another issue.
[05:13] <Bogomip_> Which itself may be potentially problematic but not strictly
related with what we are doing here.
[05:14] <kmarsden> 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] <bernt> Ok. ANother time (but it's somewhat related)
[05:15] <kmarsden> can you explain?
[05:15] <kmarsden> if it will affect what we are doing here we should consider
it.
[05:16] <bernt> Probably not. It's related to updatable resultsets.
[05:16] <kmarsden> ok. So we should state what we are doing here in terms of
behaviour.
[05:17] <kmarsden> 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] <kmarsden> next will always return false in this case.
[05:17] <kmarsden> correct?
[05:17] <Bogomip_> agreed.
[05:17] <bernt> agree.
[05:18] <kmarsden> Ok. Was there a java repro attached to the bug or just a
code snippet?
[05:18] <Bogomip_> Sorry, repro?
[05:18] <kmarsden> reproduceable case. a java program that shows the trouble.
[05:19] <Bogomip_> vs. a Code snippet which...
[05:19] <kmarsden> is a cut and paste into the jira entry.
[05:19] <kmarsden> I guess both are repros
[05:19] <kmarsden> one is ready to run the other makes you do work
[05:19] <Bogomip_> Check :-)
[05:20] <Bogomip_> Unless I am reading Jira incorrectly, it just looks like a
snippet.
[05:21] <Bogomip_> hmmm.... I believe this code snippet would involve modifying
an existing database or creating a new one.
[05:21] <kmarsden> by Extreme programming standards you always make your test
first so you know when you are done.
[05:21] <kmarsden> this is good but actually makes it hard for debugging
[05:21] <kmarsden> so I usually do both.
[05:22] <kmarsden> 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] <Bogomip_> In terms of making tests, are you talking about adding a
test to a test suite?
[05:23] <kmarsden> For a bug like this we don't want to add a new test.
[05:23] <kmarsden> as in a new java program
[05:23] <kmarsden> we just want to find something like resultset.java and add
this case into it.
[05:24] <Bogomip_> Ok, when talking about derby there are a number of
resultsets to consider which one do you mean in this context?
[05:25] <kmarsden> you mean a number of resultset tests?
[05:25] <Bogomip_> Both I guess :-)
[05:25] <Bogomip_> I'm just thinking of iapi.ResultSet, java.sql.ResultSet,
impl.jdbc.EmbeddedResultSet, etc.
[05:26] <kmarsden> oh.
[05:26] <kmarsden> I am just thinking right now about a test where we can add
our test case for this bug.
[05:26] <kmarsden> We won't go to any of those classes for this one.
[05:26] <Bogomip_> K
[05:26] <kmarsden> since it is a network server issue
[05:27] <kmarsden> In general our strategy is
[05:27] <kmarsden> 1) confirm this a bug. done
[05:27] <kmarsden> 2) Get a stand alone repro
[05:27] <kmarsden> 3) Add the test case to an existing test
[05:28] <kmarsden> 4) Check the embedded behaviour.
[05:28] <kmarsden> 5) Think of other related cases we want to test
[05:28] <kmarsden> 6) Add those to the test.
[05:29] <kmarsden> 7) Start thinking of how to fix
[05:29] <kmarsden> sould ok
[05:29] <kmarsden> ?
[05:29] <kmarsden> s/sould/sound
[05:30] <Bogomip_> Sounds alright to me.
[05:30] <Bogomip_> I'm sure you will outline where these tests will be placed
presently.
[05:30] <kmarsden> Yes.
[05:30] <kmarsden> Can you start making our stand alone repro while I go look
for a good place to hang this test
[05:31] <kmarsden> ?
[05:31] <Bogomip_> Alright, shall I use the snippet from the jira entry?
[05:31] <kmarsden> sure. That's good.
[05:33] <Bogomip_> 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] <Bogomip_> 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] <kmarsden> Well for the standalone repro we will start the server
manually.
[05:35] <Bogomip_> k
[05:35] <kmarsden> the standalone repro is sort of a throw away thing
[05:35] <kmarsden> Since the tests will be updated to include the case.
[05:36] <kmarsden> I have a template that I use. but messy. Let me look at it
[05:36] <Bogomip_> Sure.
[05:38] <kmarsden> For my repros I usually have a parameter for the connection
type, for instance.
[05:39] <kmarsden> derby213 derby
[05:39] <kmarsden> derby213 derybnetclient
[05:40] <Bogomip_> This is passed as a commandline argument and is used to
determine if the client will connect locally or via DRDA?
[05:40] <kmarsden> Right. I actually have about 11 different connection types
in this thing so it is all to messy to send you.
[05:41] <kmarsden> but here are bits
[05:41] <kmarsden> public static Connection initConn(String conntype, String
dbname) throws Exception ...
[05:41] <kmarsden> else if (conntype.equals("derby"))
[05:41] <kmarsden> {
[05:41] <kmarsden> driver =
"org.apache.derby.jdbc.EmbeddedDriver";
[05:41] <kmarsden> url = "jdbc:derby:" + dbname +
";create=true";
[05:41] <kmarsden> }
[05:41] <kmarsden> else if (conntype.equals("derbynet"))
[05:41] <kmarsden> {
[05:41] <kmarsden> driver = "com.ibm.db2.jcc.DB2Driver";
[05:41] <kmarsden> url =
"jdbc:derby:net://localhost:1527/" + dbname
+";create=true:retrieveMessagesFromServerOnGetMessage=true;";
[05:41] <kmarsden> }
[05:41] <kmarsden> that is bad in IRc
[05:42] <Bogomip_> I'm getting smileys on my side :-)
[05:42] <Bogomip_> I think I get the idea though.
[05:42] <Bogomip_> In this case will we only worry about the two connection
types?
[05:43] <kmarsden> three derbynet, derbynetclient and derby.
[05:43] <kmarsden> else if (conntype.equals("derbynetclient"))
[05:43] <kmarsden> {
[05:43] <kmarsden> driver =
"org.apache.derby.jdbc.ClientDriver";
[05:43] <kmarsden> url = "jdbc:derby://localhost:1527/" +
dbname + ";create=true";
[05:43] <kmarsden> }
[05:44] <Bogomip_> check
[05:45] <kmarsden> anyway you can reuse your Database class and this can be a
connect method that returns a Connection or something like that.
[05:46] <kmarsden> ok. I will go look for a place for this tet
[05:46] <kmarsden> test
[05:46] <Bogomip_> k, I'll try to have something for you asap.
[05:50] <kmarsden> Phillip, maybe it would be useful for uso go through this
excercise of finding a test to add our case to together.
[05:50] <kmarsden> since we just have a few more minutes this morning
[05:51] <kmarsden> ok?
[05:52] <Bogomip_> Sure.
[05:52] <Bogomip_> Would you like me to email the testcase to the list after I
am done with it?
[05:52] <kmarsden> That would be great. Do you want to do the summary, or
should I do that?
[05:54] <Bogomip_> 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] <kmarsden> Sounds good
[05:54] <kmarsden> OK. The tests
[05:54] <kmarsden> So the tests are under
java/testing/derbyTesting/functionTests/
[05:55] <kmarsden> there is a tests directory that has subdirectories for
different test categories
[05:55] <kmarsden> like store, lang, derbynet (network server), lang (SQL),
jdbcapi etc.
[05:55] <kmarsden> tests are either .sql tests (run with ij)
[05:56] <kmarsden> or .java tets
[05:56] <kmarsden> Under functionTests/suites there are a bunch of tests suites.
[05:56] <kmarsden> they do not have a 1-1 correspondence with the directories
necessarily
[05:57] <kmarsden> For network server there are two relevant suites
[05:57] <kmarsden> derbynetmats and derbynetclientmats
[05:57] <Bogomip_> I see them.
[05:57] <kmarsden> derbynetclientmats is for the new client. derbynetmats is
for the DB2 Universal JDBC Driver
[05:58] <kmarsden> Let's look at derbynetclientmats
[05:58] <kmarsden> the properties file shows the suites that will run for this
suite
[05:59] <kmarsden> 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] <kmarsden> this is just a quirky harness thng
[06:00] <Bogomip_> Alright.
[06:00] <kmarsden> in addition to the derbynetclienmats.properties file there
is a derbynetclientmats.runall file
[06:01] <kmarsden> this one shows a few individual tests that run for client
[06:01] *** bernt quit ("leaving" )
[06:02] <Bogomip_> Neither of which appear particularly relevant to our current
project.
[06:03] <kmarsden> right. Just wanted to show how the thing was structured.
[06:03] <Bogomip_> By the way if you have other obligations we can finish this
later.
[06:03] <kmarsden> So we want to change something related to ResultSet
[06:03] <kmarsden> I can go just a few more minutes
[06:03] <kmarsden> if you want to
[06:04] <Bogomip_> I have time.
[06:04] <kmarsden> ResultSet tests would be under jdbcapi
[06:04] <kmarsden> I thought jdbcapi/resultset.java
[06:05] <kmarsden> To check that this runs with network server you would need
to trace the suite.
[06:06] <kmarsden> I usually grep for which suite it is in
[06:06] <kmarsden> $ grep resultset.java *.runall
[06:06] <kmarsden> jdbcapi.runall:jdbcapi/resultset.java
[06:07] <kmarsden> then grep for that suite in the properties files
[06:07] <kmarsden> grep jdbcapi *.properties
[06:08] <Bogomip_> I'm actually using eclipse as my development environment, in
combination with dos commandline.
[06:08] <Bogomip_> Unfortunately that leaves me with a lack of grep.
[06:08] <kmarsden> #:)
[06:09] <Bogomip_> nevertheless, I can probably use a poor mans search tool to
the same effect
[06:09] <kmarsden> But anyway the jdbcpi suite does run for network server
[06:10] <kmarsden> Another easy indicator that this test is run for network
server is the fact that it has a separate master
[06:10] <kmarsden> under the master directory we have
[06:10] <kmarsden> ./resultset.out
[06:10] <kmarsden> ./DerbyNet/resultset.out
[06:10] <kmarsden> ./DerbyNetClient/resultset.out
[06:10] <kmarsden> that tells us when whe change this test we will probably
have to update three masters
[06:11] <kmarsden> Anyway resultset.java is propbably the place to put this.
[06:11] <kmarsden> So until next time.
[06:12] <Bogomip_> Aright, thank you for your time.
[06:12] <Bogomip_> When would you like next time to be?
[06:12] <kmarsden> 1) You will work on the repro. 2) I will post a summary to
the list.
[06:12] <kmarsden> Well, how about Tuesday morning?
[06:13] <Bogomip_> Sure, that would be great.
[06:13] <Bogomip_> Same time and duration?
[06:13] <kmarsden> yes
[06:13] <kmarsden> Extra credit is add our test case to resulset.java and think
of other cases we should test
[06:14] <kmarsden> It should pass for embedded
[06:14] <Bogomip_> Indeed.
[06:15] <kmarsden> ok. bye for now
[06:15] <Bogomip_> Talk to you tuesday.
[06:17] *** bernt ([EMAIL PROTECTED]) joined
[06:17] <kmarsden> thanks for your patience Bernt. We're done until Tuesday
morning.
[06:18] <bernt> No problem.
