Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 3 Feb 2012 00:44:53 +0000 (UTC)
From: "Myrna van Lunteren (Updated) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <437698983.5895.1328229893667.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (DERBY-3808) Convert subquery.sql to junit
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren updated DERBY-3808:
--------------------------------------

    Attachment: DERBY-3808_1.diff
                DERBY-3808_1.stat

Attaching a patch based on Manjula's work, ready for review.

I modified the test from Manjula's in the following ways:
- re-applied the changes made to subquery.sql (and .out) in the last 3 1/2 years
- reformatted Manjula's patch, mostly removing blank lines so the specific test steps were grouped by select statement.
- corrected one instance where autocommit was set incorrectly, resulting in fixture testSubqueryFlattning failing if all fixtures ran.
- implemented the following of Kathey's suggestions:
  - added the License header
  - set the derby.language.statementCacheSize=0 by wrapping in a SystemPropertyTestSetup.
  - used CleanDatabaseTestSetup/decorate.sql to create the initial set of tables
  - used setAutoCommit() and rollback()

I did not implement a 'usesJoinOrder' method, because I found there already were methods in RuntimeStatisticsParser that allowed to check for the desired plan details.
I used assertSequence.
Unfortunately, that did not work in one particular instance, where if I printed out the rtsp.toString, it looked on my computer as if there text on top of a tab. I have no idea how that could be achieved, but after that, the assertSequence method found no further matches. Instead of spending more time puzzling about this problem at this time, I checked the rest of the strings using another RuntimeStatisticsParser method, findStrings.

Another issue I ran into with assertSequence, is that one of the table names has an '_'. The method converts underscores to tabs, presumably attempting to make the strings in the tests more manageable. But in this case, it converted the name 'T_1' and 'T_3' to 'T\t1' and 'T\t3' and then looked for those strings, and of course couldn't find them.
I adjusted the assertSequence method to only replace _ for tabs in the first 15 characters, assuming that we'd not go further than 15 levels...

I did test this in all the tests where the method was directly or indirectly called, and they all passed.

I also ran this test on iseries - where it always failed in the master-based form - and it passed there too.

However, I have one concern before this is ready for commit: when running the test by itself, it passes, but when running it in the lang._Suite, the dependencies are different in 3 fixtures, suggesting some other test is leaving stuff behind.
 
Any suggestions??

These are the failures when run in the lang suite:
1) testExpressionNonCorrelated(org.apache.derbyTesting.functionTests.tests.lang.SubqueryTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1:
    Expected: >No open scans, etc.
16 dependencies found<
    Found:    >No open scans, etc.
37 dependencies found<
	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1215)
	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1127)
	at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1014)
	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:937)
	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:894)
	at org.apache.derbyTesting.functionTests.tests.lang.SubqueryTest.testExpressionNonCorrelated(SubqueryTest.java:316)
...
2) testDistinct(org.apache.derbyTesting.functionTests.tests.lang.SubqueryTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1:
    Expected: >No open scans, etc.
16 dependencies found<
    Found:    >No open scans, etc.
37 dependencies found<
	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1215)
	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1127)
	at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1014)
	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:937)
	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:894)
	at org.apache.derbyTesting.functionTests.tests.lang.SubqueryTest.testDistinct(SubqueryTest.java:1005)
...
3) testErrorsInNestedSubqueries(org.apache.derbyTesting.functionTests.tests.lang.SubqueryTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1:
    Expected: >No open scans, etc.
16 dependencies found<
    Found:    >No open scans, etc.
37 dependencies found<
	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1215)
	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1127)
	at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1014)
	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:937)
	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:894)
	at org.apache.derbyTesting.functionTests.tests.lang.SubqueryTest.testErrorsInNestedSubqueries(SubqueryTest.java:1622)
                
> Convert subquery.sql to junit
> -----------------------------
>
>                 Key: DERBY-3808
>                 URL: https://issues.apache.org/jira/browse/DERBY-3808
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>            Reporter: Manjula Kutty
>              Labels: derby_triage10_8
>         Attachments: DERBY-3808_1.diff, DERBY-3808_1.stat, DERBY_3808_diff_07_10.txt, DERBY_3808_stat_07_10.txt
>
>
> place holder for converting subquery.sql to junit , which gives intermittent failures with derbyall

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira