db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrna van Lunteren <m.v.lunte...@gmail.com>
Subject Re: Question about DERBY-44 test case (paging Myrna)
Date Fri, 03 Feb 2006 23:36:59 GMT
On 03 Feb 2006 22:30:46 +0100, Knut Anders Hatlen <Knut.Hatlen@sun.com>
wrote:
>
> Hi,
>
> I have a question about a test case for DERBY-44 (which appears to
> have been fixed by Myrna).
>
> In jdbcapi/parameterMetaDataJdbc30.java, I found this test case:
>
> // variation, and also test out empty string in the escape (jira 44).
> System.out.println("variation 1, testing jira 44");
> ps = con.prepareStatement("select * from sys.systables where tablename
> like ? escape ?");
> ps.setString (1, "SYS%");
> ps.setString (2, "");
> paramMetaData = ps.getParameterMetaData();
> System.out.println("parameters count for prepared statement is " +
> paramMetaData.getParameterCount());
> dumpParameterMetaData(paramMetaData);
> ps.execute();
>
> I wonder what the purpose of this test is. Is it to test that the
> escape keyword is accepted by the SQL parser/compiler, or is it to
> test that specifiying an empty escape string shouldn't cause
> ps.execute() to fail?


 It was not at all clear, but after much digging through old tests and
repros  ;-)
it appears this test is trying to make sure ERROR 22019 is returned. At one
point, passing on the empty string in a piece of code like this would
generate an StringIndexOutOfBoundsException instead of ERROR 22019 on the
ps.execute().


> The reason why I'm asking is that this case failed when I was testing
> a patch for DERBY-822. In DERBY-822, we want the client driver to
> prefetch data in the execute call. Since having an empty string as
> escape character is not allowed by the SQL spec, this test will fail
> if we do prefetching in execute(). However, the test code does not
> attempt to fetch the results from the query, so it doesn't fail if we
> don't prefetch data.
>
> To me, this test case looks a bit odd (testing that executing invalid
> SQL doesn't fail), but I thought I'd ask before changing it, in case
> there's a reason for doing it like this.


Thx for checking, I hope my reply makes sense. It was attempting to check it
didn't fail in an ugly way. I'm wondering how it's failing for you, you
didn't say.

Myrna

Mime
View raw message