Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of gcaddd-derby-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: derby-dev@db.apache.org
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Question about DERBY-44 test case (paging Myrna)
Date: 03 Feb 2006 22:30:46 +0100
Organization: Sun Microsystems
Lines: 38
Message-ID: <wkhd7gnn95.fsf@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Sender: news <news@sea.gmane.org>

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