db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@gmail.com>
Subject Re: [jira] Commented: (DERBY-827) Performance can be improved by re-using language ResultSets across Activation executions.
Date Fri, 02 Mar 2007 16:10:06 GMT
Army wrote:
> 
> Would
> 
>   JDBC.assertDrainResults(rs, 0);
> 
> solve this particular problem?  If you're expecting an empty result set 
> then when you "drain" it you should get 0 rows, so wouldn't this be an 
> appropriate check?

Oh, and I just noticed there's also:

   JDBC.assertEmpty(rs);

which does the same thing ;)

Also, in your earlier email you wrote:

 > why don't [the JDBC.assert methods] follow the standard JUnit assert
 > pattern, (assertX(String message, T expected, T returned))?

When I look at JDBC.assertFullResultSet(...), I see three assertions:

   // Assert that we have the right number of columns.
   Assert.assertEquals("Unexpected column count:",
     expectedRows[0].length, rsmd.getColumnCount());

   assertRowInResultSet(rs, rows + 1,
     expectedRows[rows], allAsTrimmedStrings);

   // And finally, assert the row count.
   Assert.assertEquals("Unexpected row count:", expectedRows.length, rows);

Is there something about these that does not follow the pattern you mention? 
Sorry if I'm missing something obvious...

Army


Mime
View raw message