db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Question about UpdateCursorTest.testVirtualMemoryHeap
Date Thu, 12 Apr 2007 23:44:14 GMT
It looks like this test is failing in the current trunk without
your changes:

http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/528002-org.apache.derbyTesting.functionTests.suites.All_diff.txt

a quick scan of the tinderbox reports here:
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/index.html

And it looks like the test has been failing ever since it was checked in:
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/526070-org.apache.derbyTesting.functionTests.suites.All_diff.txt
Changes from 525953/526069 to 526070:
------------------------------------------------------------------------
r526070 | fuzzylogic | 2007-04-06 08:20:46 +0200 (Fri, 06 Apr 2007) | 4 
lines

DERBY-2467: Convert lang/updateCursor.java to JUnit.

Committed for Ugo Matrangolo <matra@santippe.dyndns.org>

------------------------------------------------------------------------

D 
java/testing/org/apache/derbyTesting/functionTests/tests/lang/updateCursor.java
D 
java/testing/org/apache/derbyTesting/functionTests/tests/lang/updateCursor_derby.properties
U 
java/testing/org/apache/derbyTesting/functionTests/tests/lang/_Suite.java
A 
java/testing/org/apache/derbyTesting/functionTests/tests/lang/UpdateCursorTest.java
D 
java/testing/org/apache/derbyTesting/functionTests/master/updateCursor.out
U 
java/testing/org/apache/derbyTesting/functionTests/suites/derbylang.runall

Fetching external item into 'tools/testing/derby/10.1'
Updated external to revision 526070.

Updated to revision 526070.
526070 URL: https://svn.apache.org/repos/asf/db/derby/code/trunk

Performing status on external item at 'tools/testing/derby/10.1'



 From some comments in the checkin it looks like order test was added as 
a requirement for checkin, but don't know if it is the specific one you 
are highlighting.



Bryan Pendleton wrote:
> I'm a bit confused about the test program
> UpdateCursorTest.testVirtualMemoryHeap. This test program
> appears to depend on the order of the rows returned, but
> it does not contain an ORDER BY clause in the query. Here's
> the code I'm looking at, from UpdateCursorTest.java:
> 
>     /**
>      * Test the virtual memory heap.
>      *
>      * @throws SQLException
>      */
>     public void testVirtualMemoryHeap() throws SQLException {
>         PreparedStatement select = prepareStatement("select c1, c3 from 
> t1 where c3 > 1 and c1 > 0 for update");
>         Statement update = createStatement();
>         String cursorName;
>         ResultSet cursor;
>         int expectedValue = 1;
> 
>         cursor = select.executeQuery(); // cursor is now open
>         cursorName = cursor.getCursorName();
> 
>         /* scan the entire table except the last row. */
>         for (int i = 0; i < SIZE_OF_T1 - 1; i++) {
> 
>             /*  Notice the order in the rows we get: from 2 to 102 asc 
> order on second column (c3)
>              *  then from 202 down to 103 on that column; then from 203 
> up to 250.  The reason is
>              *  we are using asc index on c3, all the rows updated are 
> in the future direction of the
>              *  index scan, so they all get filled into a hash table.  
> The MAX_MEMORY_PER_TABLE
>              *  property determines max cap of hash table 100.  So from 
> row 103 it goes into virtual
>              *  memory heap, whose in memory part is also 100 entries.  
> So row 103 to 202 goes into
>              *  the in-memory part and gets dumped out in reverse 
> order.  Finally Row 203 to 250"
>              *  goes into file system.  Here we mean row ids.
>              */
> 
> This test seems to be very sensitive to the precise query execution
> strategy that is being used, but I don't see how the test is
> controlling that query execution strategy.
> 
> Can somebody clarify how the test works for me?
> 
> thanks,
> 
> bryan
> 
> P.S. The reason that I'm asking is that my proposed change for
> DERBY-2526 causes this test to fail, but I'm not sure whether that
> means my change is bad, or whether this test is depending on a
> query execution strategy that is not guaranteed to occur.
> 
> 
> 


Mime
View raw message