db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3802) Convert "org.apache.derbyTesting.functionTests.tests.lang.optimizerOverrides.sql" to junit.
Date Thu, 07 Aug 2008 07:29:44 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620535#action_12620535

Myrna van Lunteren commented on DERBY-3802:

Hi Junjie,

Great work, and apologies for not getting to this earlier.

First, I'll reply to your questions, then I have some general comments
1. well, checking for that SQLException - mentioning an EOF - that is, there is no useful
statement to be executed - would be one way. This section is a little strange in a java program,
of course, because the comments (starting with --) are fairly useless when executing a single
SQL statement from a java program; instead, you'd use java comments... But they're very useful
when you've got a biggish SQL script.
I think it would be ok if you make statements just like in the original .sql, i.e. starting
with the -- string, then followed by a \n, and *then* add some valid SQL on which you can
execute a assertFullResultSet check.
e.g., something like: 
           rs.st.executeQuery("--derby\n select * from t1");
           JDBC.assertFullResultSet(rs, FULL_TABLE);

2. I don't know what your trouble with the for update statements is... Check the manual (Reference
Guide: http://db.apache.org/derby/docs/dev/ref/rrefsqlj31783.html) for the syntax, or look
at e.g. the test lang.ForUpdateTest for examples.

3. those are good additions, thank you! I'd not add the sentence 'A test was added', though
- all the tests were added at some point. 

general comments:
- setup()/teardown() - Instead of creating the tables once per fixture, you can do it once
using CleanDatabaseSetup and decorateSQL and then the cleanup will be automatic.  See BatchUpdateTest
for an example.

- instead of getConnection().setAutoCommit(true|false), use setAutoCommit(true|false). All
appropriate processing will then be done for you and it gets the default connection using
appropriate calls.

- why did you not check the value of the runtimestatistics? That's quite important for this
test. To see how this is done in a junit test, using the org.apache.derbyTesting.junit.SQLUtilities.getRuntimeStatisticsParser,
take a look at the test lang.PredicatePushDownTest.

- and a nit: why change the name to OptimizerOverriding? The functionality is known as 'Optimizer
Overrides', see the tuning guide...(http://db.apache.org/derby/docs/dev/tuning/ctundepthoptover.html)


> Convert "org.apache.derbyTesting.functionTests.tests.lang.optimizerOverrides.sql" to
> --------------------------------------------------------------------------------------------
>                 Key: DERBY-3802
>                 URL: https://issues.apache.org/jira/browse/DERBY-3802
>             Project: Derby
>          Issue Type: Test
>          Components: Test
>            Reporter: Junjie Peng
>            Assignee: Junjie Peng
>             Fix For:
>         Attachments: derby-3802-1.patch

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message