db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lily Wei <lily...@yahoo.com>
Subject Re: [jira] Commented: (DERBY-4908) Instability in CheckConstraintTest.testBuiltInFunctions
Date Fri, 19 Nov 2010 15:26:37 GMT
Hi Knut:
    Thank you so much for fixing this issue.

    I always puzzle about this kind of change. Does this behavior mean the 
optimizer somehow change so it choose different path? Hence, the different order 
result set. Or, optimizer can decide to choose different path in general?
 

Thanks,
Lily

________________________________
From: Knut Anders Hatlen (JIRA) <jira@apache.org>
To: derby-dev@db.apache.org
Sent: Fri, November 19, 2010 1:01:14 AM
Subject: [jira] Commented: (DERBY-4908) Instability in 
CheckConstraintTest.testBuiltInFunctions


    [ 
https://issues.apache.org/jira/browse/DERBY-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933731#action_12933731
 ] 


Knut Anders Hatlen commented on DERBY-4908:
-------------------------------------------

The failing assert looks like this:

        rs = st.executeQuery(
            " select  c.type from "
            + "sys.sysconstraints c, sys.systables t where "
            + "c.tableid = t.tableid and tablename='T1'");
(...)
        expRS = new String [][]
        {
            {"P"},
            {"U"},
            {"C"},
            {"U"},
            {"C"}
        };
        
        JDBC.assertFullResultSet(rs, expRS, true);

There's no ORDER BY clause in the query, so the failure may be caused by the the 
optimizer choosing a different plan for the execution. We should probably use 
assertUnorderedResultSet() instead of assertFullResultSet() when we check the 
results.

> Instability in CheckConstraintTest.testBuiltInFunctions
> -------------------------------------------------------
>
>                 Key: DERBY-4908
>                 URL: https://issues.apache.org/jira/browse/DERBY-4908
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.7.1.0
>         Environment: java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Oracle JRockit(R) (build R28.0.1-21-133393-1.6.0_20-20100512-2126-linux-ia32, 
>compiled mode)
>            Reporter: Knut Anders Hatlen
>            Priority: Minor
>
> Saw this failure once when running suites.All on the 10.7.1.0 release 
>candidate:
> 1) 
>testBuiltInFunctions(org.apache.derbyTesting.functionTests.tests.lang.CheckConstraintTest)junit.framework.AssertionFailedError:
> Column value mismatch @ column 'TYPE', row 1:
>     Expected: >P<
>     Found:    >U<
>         at 
>org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1213)
>         at 
>org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1125)
>         at 
>org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1012)
>         at 
>org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935)
>         at 
>org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892)
>         at 
>org.apache.derbyTesting.functionTests.tests.lang.CheckConstraintTest.testBuiltInFunctions(CheckConstraintTest.java:752)
>
> The failure didn't show up when I reran the test (reran both standalone and as 
>part of suites.All).

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


      
Mime
View raw message