Re: Question about DERBY-44 test case (paging Myrna)
Myrna van Lunteren <[EMAIL PROTECTED]> writes: > On 04 Feb 2006 18:49:31 +0100, Knut Anders Hatlen <[EMAIL PROTECTED]> > wrote: > > > > It is ERROR 22019 I am seeing. Funny thing, though, that this error is > > not expected in any of the frameworks. > > > True. I was surprised. I'm wondering if something happened along the way, or > that I just had my eyes closed when I put this in. The comment is note > useful. :-/ > Maybe you'll fix it up while you're at it...? Sure, I'll do that. -- Knut Anders
Re: Question about DERBY-44 test case (paging Myrna)
Myrna van Lunteren wrote: Maybe someone can explain the difference and that can be added as a comment also? I remember vaguely something about DerbyNet by default deferring execution of prepared statements, but not DerbyNetClient; but I could be completely off on that one. Myrna You are on this one... Right on it! Satheesh
Re: Question about DERBY-44 test case (paging Myrna)
On 04 Feb 2006 18:49:31 +0100, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote: It is ERROR 22019 I am seeing. Funny thing, though, that this error isnot expected in any of the frameworks. True. I was surprised. I'm wondering if something happened along the way, or that I just had my eyes closed when I put this in. The comment is note useful. :-/ Maybe you'll fix it up while you're at it...? I guess it's okay to replace the ps.execute() line withResultSet rs = ps.executeQuery();rs.next ();so that we get ERROR 22019 in all frameworks. Hopefully, no one thinksit's a problem that DerbyNetClient fails on execute() and embedded andDerbyNet fail on next(). Makes sense to me. Maybe someone can explain the difference and that can be added as a comment also? I remember vaguely something about DerbyNet by default deferring execution of prepared statements, but not DerbyNetClient; but I could be completely off on that one. Myrna
Re: Question about DERBY-44 test case (paging Myrna)
Myrna van Lunteren <[EMAIL PROTECTED]> writes:
> On 03 Feb 2006 22:30:46 +0100, Knut Anders Hatlen <[EMAIL PROTECTED]>
> 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().
Thank you for doing the historical research! :)
It is ERROR 22019 I am seeing. Funny thing, though, that this error is
not expected in any of the frameworks.
I guess it's okay to replace the ps.execute() line with
ResultSet rs = ps.executeQuery();
rs.next();
so that we get ERROR 22019 in all frameworks. Hopefully, no one thinks
it's a problem that DerbyNetClient fails on execute() and embedded and
DerbyNet fail on next().
--
Knut Anders
Re: Question about DERBY-44 test case (paging Myrna)
On 03 Feb 2006 22:30:46 +0100, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
Hi,I have a question about a test case for DERBY-44 (which appears tohave 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 totest that specifiying an empty escape string shouldn't causeps.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 testinga patch for DERBY-822. In DERBY-822, we want the client driver to
prefetch data in the execute call. Since having an empty string asescape character is not allowed by the SQL spec, this test will failif we do prefetching in execute(). However, the test code does notattempt 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 invalidSQL doesn't fail), but I thought I'd ask before changing it, in casethere'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
Question about DERBY-44 test case (paging Myrna)
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?
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.
Thanks.
--
Knut Anders
