gjacoby126 commented on a change in pull request #592: PHOENIX-5505 Index read
repair does not repair unverified rows with h…
URL: https://github.com/apache/phoenix/pull/592#discussion_r331210564
##########
File path:
phoenix-core/src/it/java/org/apache/phoenix/end2end/index/GlobalIndexCheckerIT.java
##########
@@ -223,21 +226,52 @@ public void
testSkipDataTableAndPostIndexPartialRowUpdate() throws Exception {
IndexToolIT.runIndexTool(true, false, null, dataTableName,
indexName + "2");
}
// Configure Indexer to skip the last two write phase (i.e., the data
table update and post index update phase)
- // and check that this does not impact the correctness
+ // and check that this does not impact the correctness (one overwrite)
IndexRegionObserver.setSkipDataTableUpdatesForTesting(true);
IndexRegionObserver.setSkipPostIndexUpdatesForTesting(true);
conn.createStatement().execute("upsert into " + dataTableName + " (id,
val2) values ('a', 'abcc')");
conn.commit();
IndexRegionObserver.setSkipDataTableUpdatesForTesting(false);
IndexRegionObserver.setSkipPostIndexUpdatesForTesting(false);
- conn.createStatement().execute("upsert into " + dataTableName + " (id,
val3) values ('a', 'abcdd')");
- conn.commit();
String selectSql = "SELECT val2, val3 from " + dataTableName + "
WHERE val1 = 'ab'";
// Verify that we will read from the first index table
assertExplainPlan(conn, selectSql, dataTableName, indexName + "1");
ResultSet rs = conn.createStatement().executeQuery(selectSql);
assertTrue(rs.next());
assertEquals("abc", rs.getString(1));
+ assertEquals("abcd", rs.getString(2));
+ assertFalse(rs.next());
+ // Configure Indexer to skip the last two write phase (i.e., the data
table update and post index update phase)
+ // and check that this does not impact the correctness (two overwrites)
+ IndexRegionObserver.setSkipDataTableUpdatesForTesting(true);
+ IndexRegionObserver.setSkipPostIndexUpdatesForTesting(true);
+ conn.createStatement().execute("upsert into " + dataTableName + " (id,
val2) values ('a', 'abccc')");
+ conn.commit();
+ conn.createStatement().execute("upsert into " + dataTableName + " (id,
val2) values ('a', 'abcccc')");
+ conn.commit();
+ IndexRegionObserver.setSkipDataTableUpdatesForTesting(false);
+ IndexRegionObserver.setSkipPostIndexUpdatesForTesting(false);
+ // Verify that we will read from the first index table
+ assertExplainPlan(conn, selectSql, dataTableName, indexName + "1");
+ rs = conn.createStatement().executeQuery(selectSql);
+ assertTrue(rs.next());
+ assertEquals("abc", rs.getString(1));
+ assertEquals("abcd", rs.getString(2));
+ assertFalse(rs.next());
+ selectSql = "SELECT val2, val3 from " + dataTableName + " WHERE val2
= 'abcc'";
+ // Verify that we will read from the second index table
+ assertExplainPlan(conn, selectSql, dataTableName, indexName + "2");
+ rs = conn.createStatement().executeQuery(selectSql);
Review comment:
Shouldn't this return a row because updating {a, abcc} -> {a, abccc}
happened when we skipped the stage 2 and 3 updates above, and so the initial
population on line 232 should still be live in index 2?
(Also, this would be clearer if before each query you explained what you
expected to find and why -- reverse engineering them requires very closely
reading the entire function plus the populate helper function)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
