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.
