db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yip Ng (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2048) LangScripts JUnit test fails in views.sql
Date Tue, 07 Nov 2006 20:00:52 GMT
    [ http://issues.apache.org/jira/browse/DERBY-2048?page=comments#action_12447914 ] 
Yip Ng commented on DERBY-2048:

Ah yes, it cleans up more than just user tables.  My mistake.  =)  From what I see from the
clean up code in the Derby JUnit utility class, it does a pretty good job of cleaning up all
the user schema objects.  So it puzzled me why there would be an ordering diff.

It so happens that the ordering diff is on an error message that is directly related to the
system table SYS.SYSDEPENDS.  The stored dependency entries that get populated are from the
JUnit infrastructure (and not the script itself) during CleanDatabaseTestSetup.setUp() and
its tearDown() method when it attempts to clean the database objects via its removeObjects()
method and it made use of metadata calls to accomplish this.  Those metadata calls made to
Derby are the following and their associated stored dependencies are populated in SYS.SYSDEPENDS
(32 entries):  


When those SPSDescriptors get prepared via its prepareAndRelease() method in the generate
phase, the stored dependency entries are cleared out based on the dependent UUID first and
then are populated again in SYS.SYSDEPENDS.  So based on this observation, there are row insertions
and deletions in SYS.SYSDEPENDS in each setUp() and tearDown().  So the ordering of those
rows when fetched in an unordered way may depend on how the store subsystem manages free space.

> LangScripts JUnit test fails in views.sql
> -----------------------------------------
>                 Key: DERBY-2048
>                 URL: http://issues.apache.org/jira/browse/DERBY-2048
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions:
>         Environment: Windows XP
>            Reporter: Yip Ng
> LangScripts JUnit test fails in views.sql
> There was 1 failure:
> 1) views(org.apache.derbyTesting.functionTests.tests.lang.LangScripts )junit.fram
> ework.ComparisonFailure: Output at line 104 expected:<...T1' because VIEW 'SV[1]'
is dependent on th...> but was:<...T1' because VIEW 'SV[2]' is dependent on th...>
>         at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100)
>         at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:117)
>         at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>         at junit.extensions.TestSetup.run(TestSetup.java:25)
> Tests run: 2016,  Failures: 1,  Errors: 0
> Some observations:
> If org.apache.derbyTesting.functionTests.tests.lang.LangScripts is used to run views.sql
as a single test, then it ran smoothly without a problem.
> .
> Time: 7.109
> OK (1 test)
> But if views.sql is run as part of a suite, then the ordering diff occurs.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message