Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-6623

DatabaseMetaDataTest fails intermittently

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 10.10.2.0
    • 10.11.1.1, 10.12.1.1
    • Test
    • None
    • Regression Test Failure

    Description

      Saw this on the trunk [http://download.java.net/javadesktop/derby/request_5592737/javadb-task-3883745.html[regression tests]]:

      testGetXXportedKeys:

      junit.framework.AssertionFailedError: Column value mismatch @ column 'FK_NAME', row 3:
          Expected: >FKEY3<
          Found:    >FKEY2<
      	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1303)
      	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1215)
      	at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1102)
      	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1025)
      	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:982)
      	at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.assertFullResultSet(DatabaseMetaDataTest.java:3930)
      	at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetXXportedKeys(DatabaseMetaDataTest.java:4117)
      	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:118)
      	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:440)
      	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:457)
      

      Attachments

        1. derby-6623.diff
          48 kB
          Dag H. Wanvik
        2. derby-6623-2.diff
          4 kB
          Dag H. Wanvik
        3. derby-6623-2a.diff
          4 kB
          Dag H. Wanvik
        4. derby-6623-2a.status
          0.9 kB
          Dag H. Wanvik
        5. derby-6623-3.diff
          2 kB
          Dag H. Wanvik

        Issue Links

          Activity

            dagw Dag H. Wanvik added a comment -

            I notice that the value FKEY3 (and FKEY2) in the test are foreign keys. Looking at the test, we are asking for imported keys (line 4116).The query we use (internally) for embedded metadata queries (cd java/engine/org/apache/derby/impl/jdbc/metadata.properties query "getImportedKeys") has the following
            ORDER BY clause at the end:

            "ORDER BY PKTABLE_CAT,  \
            				PKTABLE_SCHEM, \
            				PKTABLE_NAME, \
            				PK_NAME, \
            				KEY_SEQ
            

            As far as I can, it does not order the rows on FK_NAME, which is the foreign key name. This could possibly be the reason the rows come back in an unexpected order in the test.

            dagw Dag H. Wanvik added a comment - I notice that the value FKEY3 (and FKEY2) in the test are foreign keys. Looking at the test, we are asking for imported keys (line 4116).The query we use (internally) for embedded metadata queries (cd java/engine/org/apache/derby/impl/jdbc/metadata.properties query "getImportedKeys") has the following ORDER BY clause at the end: "ORDER BY PKTABLE_CAT, \ PKTABLE_SCHEM, \ PKTABLE_NAME, \ PK_NAME, \ KEY_SEQ As far as I can, it does not order the rows on FK_NAME, which is the foreign key name. This could possibly be the reason the rows come back in an unexpected order in the test.
            dagw Dag H. Wanvik added a comment -

            Looking at the API specification for DatabaseMetaData#getImported keys I see:

            They are ordered by PKTABLE_CAT, PKTABLE_SCHEM, PKTABLE_NAME, and KEY_SEQ.

            For the foreign keys FKEY2 and FKEY3, I think all these values can be equal since they both refer to the same
            primary key in the primary table ("C30", "S").

            dagw Dag H. Wanvik added a comment - Looking at the API specification for DatabaseMetaData#getImported keys I see: They are ordered by PKTABLE_CAT, PKTABLE_SCHEM, PKTABLE_NAME, and KEY_SEQ. For the foreign keys FKEY2 and FKEY3, I think all these values can be equal since they both refer to the same primary key in the primary table ("C30", "S").
            dagw Dag H. Wanvik added a comment -

            One solution would be have the test use JDBC#assertUnorderedResultSet.

            dagw Dag H. Wanvik added a comment - One solution would be have the test use JDBC#assertUnorderedResultSet.
            dagw Dag H. Wanvik added a comment -

            Patch derby-6623.diff introduces JDBC#assertunorderedResultSet to solve the issue. It also cleans up a number of IDE warnings (missing Javadocs, old style loop code, variable shadowing).

            Running regressions.

            dagw Dag H. Wanvik added a comment - Patch derby-6623.diff introduces JDBC#assertunorderedResultSet to solve the issue. It also cleans up a number of IDE warnings (missing Javadocs, old style loop code, variable shadowing). Running regressions.

            Commit 1603944 from dagw in branch 'code/trunk'
            [ https://svn.apache.org/r1603944 ]

            DERBY-6623 DatabaseMetaDataTest fails intermittently

            Patch derby-6623 introduced JDBC#assertunorderedResultSet to solve the
            issue. It also cleans up a number of IDE warnings (missing Javadocs,
            old style loop code, variable shadowing).

            jira-bot ASF subversion and git services added a comment - Commit 1603944 from dagw in branch 'code/trunk' [ https://svn.apache.org/r1603944 ] DERBY-6623 DatabaseMetaDataTest fails intermittently Patch derby-6623 introduced JDBC#assertunorderedResultSet to solve the issue. It also cleans up a number of IDE warnings (missing Javadocs, old style loop code, variable shadowing).
            dagw Dag H. Wanvik added a comment -

            Reopening - last night I saw another error in the nightly regressions on trunk:

            http://download.java.net/javadesktop/derby/request_5593027

            with this signature:

            org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetBestRowIdentifier

            stack trace.

            junit.framework.AssertionFailedError: Column value mismatch @ column 'COLUMN_NAME', row 1:
                Expected: >J<
                Found:    >I<
            	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1303)
            	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1215)
            	at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1102)
            	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1025)
            	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:982)
            	at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.verifyBRIResults(DatabaseMetaDataTest.java:3729)
            	at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetBestRowIdentifier(DatabaseMetaDataTest.java:3485)
            	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:118)
            	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:440)
            	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:457)
            
            dagw Dag H. Wanvik added a comment - Reopening - last night I saw another error in the nightly regressions on trunk: http://download.java.net/javadesktop/derby/request_5593027 with this signature: org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetBestRowIdentifier stack trace. junit.framework.AssertionFailedError: Column value mismatch @ column 'COLUMN_NAME' , row 1: Expected: >J< Found: >I< at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1303) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1215) at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1102) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1025) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:982) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.verifyBRIResults(DatabaseMetaDataTest.java:3729) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetBestRowIdentifier(DatabaseMetaDataTest.java:3485) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:118) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:440) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:457)
            dagw Dag H. Wanvik added a comment -

            This time, the instability is in the method EmbedDatabaseMetaData#getBestRowIdentifier. The table in question looks like this:

            create table brit3 (i int not null unique, j int not null unique)  -- cf line 3405 in DatabaseMetaDataTest
            

            Now, the Javadoc for the DBMD method says:

            "Retrieves a description of a table's optimal set of columns that uniquely identifies a row. They are ordered by SCOPE. "

            In "metadata.properties" I see this internal query for this method:

            getBestRowIdentifierUniqueConstraint=\
            	SELECT CONS.CONSTRAINTID, IDX.DESCRIPTOR.numberOfOrderedColumns() AS NUMCOLS \
            	FROM SYS.SYSSCHEMAS SCHEMAS, SYS.SYSTABLES TABS, \
            		SYS.SYSCONSTRAINTS cons, SYS.SYSKEYS keys, SYS.SYSCONGLOMERATES IDX \
            	WHERE TABS.TABLEID = conS.TABLEID AND SCHEMAS.SCHEMAID = TABS.SCHEMAID \
            		AND conS.CONSTRAINTID = KEYS.CONSTRAINTID AND IDX.DESCRIPTOR IS NOT NULL \
            		AND KEYS.CONGLOMERATEID = IDX.CONGLOMERATEID AND IDX.ISCONSTRAINT \
            		AND conS.type = 'U' \
            		AND ((1=1) OR ? IS NOT NULL) \
            		AND (SCHEMAS.SCHEMANAME LIKE ?) \
            		AND (TABS.TABLENAME=?) \
            	ORDER BY NUMCOLS
            

            Now, in this case, the table has two columns which both are declared as UNIQUE NOT NULL and the query returns both, but it does not specify an order between them.

            The code that analyzes the query (EmbedDatabaseeMetaData#doGetBestRowId) has this section:

            // see if there is a primary key, use it.
            ps = getPreparedQuery("getBestRowIdentifierPrimaryKey");
            
            :   (not the case here, so we proceed to look at unique columns)
            // get the unique constraint with the fewest columns.
            ps = getPreparedQuery("getBestRowIdentifierUniqueConstraint");
            ps.setString(1,catalogPattern);
            ps.setString(2,schemaPattern);
            ps.setString(3,table);
            
            rs = ps.executeQuery();
            done = rs.next();
            if (done) {
                constraintId = rs.getString(1);
            }
            

            As can be seen, once a row is read, that row is used. The test asserts it to be "J", but in the failing regression it was in fact "I", which is allowed since no ordering is specified on which constraint to return first. I presume what happened was that another query plan was used which gave the rows in the opposite order, causing the assert error.

            Both unique constraints are equally good here, so which should be returned? Both? The API Javadoc doesn't really address this scenario, nor does the Derby code.

            dagw Dag H. Wanvik added a comment - This time, the instability is in the method EmbedDatabaseMetaData#getBestRowIdentifier. The table in question looks like this: create table brit3 (i int not null unique, j int not null unique) -- cf line 3405 in DatabaseMetaDataTest Now, the Javadoc for the DBMD method says: "Retrieves a description of a table's optimal set of columns that uniquely identifies a row. They are ordered by SCOPE. " In "metadata.properties" I see this internal query for this method: getBestRowIdentifierUniqueConstraint=\ SELECT CONS.CONSTRAINTID, IDX.DESCRIPTOR.numberOfOrderedColumns() AS NUMCOLS \ FROM SYS.SYSSCHEMAS SCHEMAS, SYS.SYSTABLES TABS, \ SYS.SYSCONSTRAINTS cons, SYS.SYSKEYS keys, SYS.SYSCONGLOMERATES IDX \ WHERE TABS.TABLEID = conS.TABLEID AND SCHEMAS.SCHEMAID = TABS.SCHEMAID \ AND conS.CONSTRAINTID = KEYS.CONSTRAINTID AND IDX.DESCRIPTOR IS NOT NULL \ AND KEYS.CONGLOMERATEID = IDX.CONGLOMERATEID AND IDX.ISCONSTRAINT \ AND conS.type = 'U' \ AND ((1=1) OR ? IS NOT NULL) \ AND (SCHEMAS.SCHEMANAME LIKE ?) \ AND (TABS.TABLENAME=?) \ ORDER BY NUMCOLS Now, in this case, the table has two columns which both are declared as UNIQUE NOT NULL and the query returns both, but it does not specify an order between them. The code that analyzes the query (EmbedDatabaseeMetaData#doGetBestRowId) has this section: // see if there is a primary key, use it. ps = getPreparedQuery( "getBestRowIdentifierPrimaryKey" ); : (not the case here, so we proceed to look at unique columns) // get the unique constraint with the fewest columns. ps = getPreparedQuery( "getBestRowIdentifierUniqueConstraint" ); ps.setString(1,catalogPattern); ps.setString(2,schemaPattern); ps.setString(3,table); rs = ps.executeQuery(); done = rs.next(); if (done) { constraintId = rs.getString(1); } As can be seen, once a row is read, that row is used. The test asserts it to be "J", but in the failing regression it was in fact "I", which is allowed since no ordering is specified on which constraint to return first. I presume what happened was that another query plan was used which gave the rows in the opposite order, causing the assert error. Both unique constraints are equally good here, so which should be returned? Both? The API Javadoc doesn't really address this scenario, nor does the Derby code.

            My expectation would be that it only returned one of them. The javadoc says: "Retrieves a description of a table's optimal set of columns that uniquely identifies a row." And (I, J) sounds like a less optimal set than (I) or (J), since it's bigger and has some redundancy.

            I think the current behaviour is fine, but I see no harm in adding some extra ordering so that it is deterministic which constraint is used in case of ties.

            The reference manual actually has a topic that describes how getBestRowIdentifier() works. It's more detailed than the JDBC specification, but it does not say anything about ties.

            knutanders Knut Anders Hatlen added a comment - My expectation would be that it only returned one of them. The javadoc says: "Retrieves a description of a table's optimal set of columns that uniquely identifies a row." And (I, J) sounds like a less optimal set than (I) or (J), since it's bigger and has some redundancy. I think the current behaviour is fine, but I see no harm in adding some extra ordering so that it is deterministic which constraint is used in case of ties. The reference manual actually has a topic that describes how getBestRowIdentifier() works. It's more detailed than the JDBC specification, but it does not say anything about ties.

            Seen again during last night's run on Solaris_amd64_jdk8 against the head of the 10.11.1 trunk: http://javadb.se.oracle.com/javadb-testing/request_5593027/

            rhillegas Richard N. Hillegas added a comment - Seen again during last night's run on Solaris_amd64_jdk8 against the head of the 10.11.1 trunk: http://javadb.se.oracle.com/javadb-testing/request_5593027/
            dagw Dag H. Wanvik added a comment -

            Yes, I think users would appreciate if such queries were deterministic... I'll make a patch to that effect.

            dagw Dag H. Wanvik added a comment - Yes, I think users would appreciate if such queries were deterministic... I'll make a patch to that effect.
            dagw Dag H. Wanvik added a comment - - edited

            Attaching [^derby-6623-2], which adds an extra ordering using IndexDescriptor's toString-method. This imposes a total order on the rows returned from the metadata query, so hopefully we get rid of the Heisenbug. Note that this caused another unique constraint to be chosen in the example that failed. DababaseMetaDataTest passed. Re-running regressions.

            dagw Dag H. Wanvik added a comment - - edited Attaching [^derby-6623-2] , which adds an extra ordering using IndexDescriptor's toString-method. This imposes a total order on the rows returned from the metadata query, so hopefully we get rid of the Heisenbug. Note that this caused another unique constraint to be chosen in the example that failed. DababaseMetaDataTest passed. Re-running regressions.
            dagw Dag H. Wanvik added a comment -

            One could argue that it fragile to use the toString method in this way. I did it to avoid having to extend the IndexDescriptor interface with another method with an ordering value. But we could consider

            adding some such:
            IndexDescriptor#getFirstBaseColumn

            and order on that. Opinions?

            dagw Dag H. Wanvik added a comment - One could argue that it fragile to use the toString method in this way. I did it to avoid having to extend the IndexDescriptor interface with another method with an ordering value. But we could consider adding some such: IndexDescriptor#getFirstBaseColumn and order on that. Opinions?

            Maybe it would be good enough to order by SYS.SYSCONSTRAINTS.CONSTRAINTNAME? So that in case of a tie the alphabetically first constraint/index would be chosen?

            knutanders Knut Anders Hatlen added a comment - Maybe it would be good enough to order by SYS.SYSCONSTRAINTS.CONSTRAINTNAME? So that in case of a tie the alphabetically first constraint/index would be chosen?
            dagw Dag H. Wanvik added a comment -

            Attaching patch version 2b: changed to sorting on the output of Arrays.toString(IndexDescriptor.baseColumnPosition). This makes sorting stable iff:

            • the row layout doesn't change
            • no indexes or constraint are added or removed.

            Mostly, indexes with early base columns will be sorted first (and selected as best), although not always: "[11,1]" sorts before "[2,1]", but the main thing is the same index will be selected for the same (unchanged) database always. Rerunning regressions.

            dagw Dag H. Wanvik added a comment - Attaching patch version 2b: changed to sorting on the output of Arrays.toString(IndexDescriptor.baseColumnPosition). This makes sorting stable iff: the row layout doesn't change no indexes or constraint are added or removed. Mostly, indexes with early base columns will be sorted first (and selected as best), although not always: " [11,1] " sorts before " [2,1] ", but the main thing is the same index will be selected for the same (unchanged) database always. Rerunning regressions.

            Commit 1605478 from dagw in branch 'code/trunk'
            [ https://svn.apache.org/r1605478 ]

            DERBY-6623 DatabaseMetaDataTest fails intermittently

            Patch derby-6623-2a, which adds an extra ordering [1] using
            IndexDescriptor's getBaseColumns method as input to
            Arrays.toString(). This imposes a total order on the rows returned
            from the metadata query, so hopefully we get rid of the
            Heisenbug. Note that this caused another unique constraint to be
            chosen in the example that failed.

            [1] after the number of columns in the index: small numbers
            before higher numbers since constraints with a small number of
            columns are considered better

            The ordering makes sorting stable iff:

            • the row layout doesn't change
            • no indexes or constraint are added or removed.

            Mostly, indexes with early base columns will be sorted first (and
            selected as best), although not always: "[11,1]" sorts before "[2,1]",
            but the main thing is the same index will be selected for the same
            (unchanged) database always.

            jira-bot ASF subversion and git services added a comment - Commit 1605478 from dagw in branch 'code/trunk' [ https://svn.apache.org/r1605478 ] DERBY-6623 DatabaseMetaDataTest fails intermittently Patch derby-6623-2a , which adds an extra ordering [1] using IndexDescriptor's getBaseColumns method as input to Arrays.toString() . This imposes a total order on the rows returned from the metadata query, so hopefully we get rid of the Heisenbug. Note that this caused another unique constraint to be chosen in the example that failed. [1] after the number of columns in the index: small numbers before higher numbers since constraints with a small number of columns are considered better The ordering makes sorting stable iff: the row layout doesn't change no indexes or constraint are added or removed. Mostly, indexes with early base columns will be sorted first (and selected as best), although not always: " [11,1] " sorts before " [2,1] ", but the main thing is the same index will be selected for the same (unchanged) database always.
            dagw Dag H. Wanvik added a comment -

            Reopening this, I saw this error on http://download.java.net/javadesktop/derby/request_5594301/javadb-task-3907241.html

            junit.framework.AssertionFailedError: Column value mismatch @ column 'FK_NAME', row 3:
                Expected: >FKEY3<
                Found:    >FKEY2<
            
                PKTABLE_CAT,PKTABLE_SCHEM,PKTABLE_NAME,PKCOLUMN_NAME,FKTABLE_CAT,FKTABLE_SCHEM,FKTABLE_NAME,FKCOLUMN_NAME,KEY_SEQ,UPDATE_RULE,DELETE_RULE,FK_NAME,PK_NAME,DEFERRABILITY
                ----------- ------------- ------------ ------------- ----------- ------------- ------------ ------------- ------- ----------- ----------- ------- ------- -------------
               [, DMDT, KT1, VC10, , DMDT, REFTAB, VC10, 1, 3, 3, FKEY1, PRIMKEY, 7]
               [, DMDT, KT1, I, , DMDT, REFTAB, I, 2, 3, 3, FKEY1, PRIMKEY, 7]
               [, DMDT, KT1, C30, , DMDT, REFTAB, C30, 1, 3, 3, FKEY2, UNIQUEKEY, 7]
               [, DMDT, KT1, C30, , DMDT, REFTAB, C30, 1, 3, 3, FKEY3, UNIQUEKEY, 7]
               [, DMDT, KT1, S, , DMDT, REFTAB, S2, 2, 3, 3, FKEY2, UNIQUEKEY, 7]
               [, DMDT, KT1, S, , DMDT, REFTAB, S, 2, 3, 3, FKEY3, UNIQUEKEY, 7]
               [, DMDT, REFTAB, DPRIM, , DMDT, REFTAB, DFOR, 1, 3, 3, FKEYSELF, PKEY_REFTAB, 7]
            
            	at org.apache.derbyTesting.junit.BaseTestCase.newAssertionFailedError(BaseTestCase.java:1164)
            	at org.apache.derbyTesting.junit.JDBC.addRsToReport(JDBC.java:1878)
            	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1377)
            	at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1275)
            	at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1137)
            	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1048)
            	at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1005)
            	at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.assertFullResultSet(DatabaseMetaDataTest.java:4111)
            	at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetXXportedKeys(DatabaseMetaDataTest.java:4331)
            
            dagw Dag H. Wanvik added a comment - Reopening this, I saw this error on http://download.java.net/javadesktop/derby/request_5594301/javadb-task-3907241.html junit.framework.AssertionFailedError: Column value mismatch @ column 'FK_NAME' , row 3: Expected: >FKEY3< Found: >FKEY2< PKTABLE_CAT,PKTABLE_SCHEM,PKTABLE_NAME,PKCOLUMN_NAME,FKTABLE_CAT,FKTABLE_SCHEM,FKTABLE_NAME,FKCOLUMN_NAME,KEY_SEQ,UPDATE_RULE,DELETE_RULE,FK_NAME,PK_NAME,DEFERRABILITY ----------- ------------- ------------ ------------- ----------- ------------- ------------ ------------- ------- ----------- ----------- ------- ------- ------------- [, DMDT, KT1, VC10, , DMDT, REFTAB, VC10, 1, 3, 3, FKEY1, PRIMKEY, 7] [, DMDT, KT1, I, , DMDT, REFTAB, I, 2, 3, 3, FKEY1, PRIMKEY, 7] [, DMDT, KT1, C30, , DMDT, REFTAB, C30, 1, 3, 3, FKEY2, UNIQUEKEY, 7] [, DMDT, KT1, C30, , DMDT, REFTAB, C30, 1, 3, 3, FKEY3, UNIQUEKEY, 7] [, DMDT, KT1, S, , DMDT, REFTAB, S2, 2, 3, 3, FKEY2, UNIQUEKEY, 7] [, DMDT, KT1, S, , DMDT, REFTAB, S, 2, 3, 3, FKEY3, UNIQUEKEY, 7] [, DMDT, REFTAB, DPRIM, , DMDT, REFTAB, DFOR, 1, 3, 3, FKEYSELF, PKEY_REFTAB, 7] at org.apache.derbyTesting.junit.BaseTestCase.newAssertionFailedError(BaseTestCase.java:1164) at org.apache.derbyTesting.junit.JDBC.addRsToReport(JDBC.java:1878) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1377) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1275) at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1137) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1048) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:1005) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.assertFullResultSet(DatabaseMetaDataTest.java:4111) at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetXXportedKeys(DatabaseMetaDataTest.java:4331)
            dagw Dag H. Wanvik added a comment -

            Now, the expected set of rows is:

            {"",schema,"KT1","VC10","",schema,"REFTAB","VC10","1","3","3","FKEY1","PRIMKEY","7"},
            {"",schema,"KT1","I","",schema,"REFTAB","I","2","3","3","FKEY1","PRIMKEY","7"},
            {"",schema,"KT1","C30","",schema,"REFTAB","C30","1","3","3","FKEY3","UNIQUEKEY","7"},
            {"",schema,"KT1","C30","",schema,"REFTAB","C30","1","3","3","FKEY2","UNIQUEKEY","7"},
            {"",schema,"KT1","S","",schema,"REFTAB","S","2","3","3","FKEY3","UNIQUEKEY","7"},
            {"",schema,"KT1","S","",schema,"REFTAB","S2","2","3","3","FKEY2","UNIQUEKEY","7"},
            {"",schema,"REFTAB","DPRIM","",schema,"REFTAB","DFOR","1","3","3","FKEYSELF","PKEY_REFTAB","7"}};
            

            so we can see that row #3 and #4 have changed places.

            dagw Dag H. Wanvik added a comment - Now, the expected set of rows is: { "",schema," KT1 "," VC10 "," ",schema," REFTAB "," VC10 "," 1 "," 3 "," 3 "," FKEY1 "," PRIMKEY "," 7"}, { "",schema," KT1 "," I "," ",schema," REFTAB "," I "," 2 "," 3 "," 3 "," FKEY1 "," PRIMKEY "," 7"}, { "",schema," KT1 "," C30 "," ",schema," REFTAB "," C30 "," 1 "," 3 "," 3 "," FKEY3 "," UNIQUEKEY "," 7"}, { "",schema," KT1 "," C30 "," ",schema," REFTAB "," C30 "," 1 "," 3 "," 3 "," FKEY2 "," UNIQUEKEY "," 7"}, { "",schema," KT1 "," S "," ",schema," REFTAB "," S "," 2 "," 3 "," 3 "," FKEY3 "," UNIQUEKEY "," 7"}, { "",schema," KT1 "," S "," ",schema," REFTAB "," S2 "," 2 "," 3 "," 3 "," FKEY2 "," UNIQUEKEY "," 7"}, { "",schema," REFTAB "," DPRIM "," ",schema," REFTAB "," DFOR "," 1 "," 3 "," 3 "," FKEYSELF "," PKEY_REFTAB "," 7"}}; so we can see that row #3 and #4 have changed places.
            dagw Dag H. Wanvik added a comment -

            Attaching derby-6623-3.diff:

            Another instance of the test neglecting to consider that the rows may
            legitimately come back in another order. Switched to using
            assertFullUnorderedResultSet instead of assertFullResultSet.

            dagw Dag H. Wanvik added a comment - Attaching derby-6623-3.diff : Another instance of the test neglecting to consider that the rows may legitimately come back in another order. Switched to using assertFullUnorderedResultSet instead of assertFullResultSet .

            Commit 1615821 from dagw in branch 'code/trunk'
            [ https://svn.apache.org/r1615821 ]

            DERBY-6623 DatabaseMetaDataTest fails intermittently

            Another instance of the test neglecting to consider that the rows may
            legimimately come back in another order. Switched to using
            assertFullUnorderedResultSet instead of assertFullResultSet.

            jira-bot ASF subversion and git services added a comment - Commit 1615821 from dagw in branch 'code/trunk' [ https://svn.apache.org/r1615821 ] DERBY-6623 DatabaseMetaDataTest fails intermittently Another instance of the test neglecting to consider that the rows may legimimately come back in another order. Switched to using assertFullUnorderedResultSet instead of assertFullResultSet .

            Commit 1616520 from dagw in branch 'code/branches/10.11'
            [ https://svn.apache.org/r1616520 ]

            DERBY-6623 DatabaseMetaDataTest fails intermittently

            Backported cleanly from trunk as:

            svn merge -c 1615821 https://svn.apache.org/repos/asf/db/derby/code/trunk

            Another instance of the test neglecting to consider that the rows may
            legimimately come back in another order. Switched to using
            assertFullUnorderedResultSet instead of assertFullResultSet.

            jira-bot ASF subversion and git services added a comment - Commit 1616520 from dagw in branch 'code/branches/10.11' [ https://svn.apache.org/r1616520 ] DERBY-6623 DatabaseMetaDataTest fails intermittently Backported cleanly from trunk as: svn merge -c 1615821 https://svn.apache.org/repos/asf/db/derby/code/trunk Another instance of the test neglecting to consider that the rows may legimimately come back in another order. Switched to using assertFullUnorderedResultSet instead of assertFullResultSet.

            People

              dagw Dag H. Wanvik
              dagw Dag H. Wanvik
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: