Class TestStoreScanner
java.lang.Object
org.apache.hadoop.hbase.regionserver.TestStoreScanner
-
Nested Class Summary
Modifier and TypeClassDescriptionprivate static class
A StoreScanner for our CELL_GRID above.private static class
private static class
private static class
-
Field Summary
Modifier and TypeFieldDescriptionprivate static final org.apache.hadoop.hbase.Cell[]
Five rows by four columns distinguished by column qualifier (column qualifier is one of the four rows...private static final int
private static final int
private static final int
private static final int
private static final org.apache.hadoop.hbase.Cell[]
private static final int
private static final byte[]
private static final String
static final HBaseClassTestRule
(package private) static org.apache.hadoop.conf.Configuration
private static final byte[]
private static final byte[]
private static final org.apache.hadoop.hbase.KeyValue[]
private static final org.slf4j.Logger
org.junit.rules.TestName
private static final byte[]
private org.apache.hadoop.hbase.regionserver.ScanInfo
private static final HBaseTestingUtility
private static final byte[]
private static final byte[]
private static final byte[]
private static final byte[]
private static final byte[]
From here on down, we have a bunch of defines and specific CELL_GRID of Cells.private static final byte[]
-
Constructor Summary
-
Method Summary
Modifier and TypeMethodDescription(package private) NavigableSet<byte[]>
void
void
void
void
void
void
void
void
Ensure that expired delete family markers don't override valid putsvoid
void
void
void
Test optimize in StoreScanner.void
Ensure the optimize Scan method in StoreScanner does not get in the way of a Get doing minimum work...void
Ensure that optimize does not cause the Get to do more seeking than required.void
testPeek()
void
void
void
void
void
void
void
void
void
void
void
void
-
Field Details
-
CLASS_RULE
-
LOG
-
name
-
CF_STR
- See Also:
-
CF
-
CONF
-
TEST_UTIL
-
scanInfo
-
ZERO
From here on down, we have a bunch of defines and specific CELL_GRID of Cells. The CELL_GRID then has a Scanner that can fake out 'block' transitions. All this elaborate setup is for tests that ensure we don't overread, and that theStoreScanner
is not overly enthusiastic. -
ZERO_POINT_ZERO
-
ONE
-
TWO
-
TWO_POINT_TWO
-
THREE
-
FOUR
-
FIVE
-
VALUE
-
CELL_GRID_BLOCK2_BOUNDARY
- See Also:
-
CELL_GRID_BLOCK3_BOUNDARY
- See Also:
-
CELL_GRID_BLOCK4_BOUNDARY
- See Also:
-
CELL_GRID_BLOCK5_BOUNDARY
- See Also:
-
CELL_GRID
Five rows by four columns distinguished by column qualifier (column qualifier is one of the four rows... ONE, TWO, etc.). Exceptions are a weird row after TWO; it is TWO_POINT_TWO. And then row FOUR has five columns finishing w/ row FIVE having a single column. We will use this to test scan does the right thing as it we do Gets, StoreScanner#optimize, and what we do on (faked) block boundaries. -
CELL_WITH_VERSIONS_BLOCK2_BOUNDARY
- See Also:
-
CELL_WITH_VERSIONS
-
kvs
-
-
Constructor Details
-
TestStoreScanner
public TestStoreScanner()
-
-
Method Details
-
testWithColumnCountGetFilter
- Throws:
Exception
-
getCols
-
testFullRowGetDoesNotOverreadWhenRowInsideOneBlock
- Throws:
IOException
-
testFullRowSpansBlocks
- Throws:
IOException
-
testOptimize
Test optimize in StoreScanner. Test that we skip to the next 'block' when we it makes sense reading the block 'index'.- Throws:
IOException
-
testOptimizeAndGet
Ensure the optimize Scan method in StoreScanner does not get in the way of a Get doing minimum work... seeking to start of block and then SKIPPING until we find the wanted Cell. This 'simple' scenario mimics case of all Cells fitting inside a single HFileBlock. See HBASE-15392. This test is a little cryptic. Takes a bit of staring to figure what it up to.- Throws:
IOException
-
testOptimizeAndGetWithFakedNextBlockIndexStart
Ensure that optimize does not cause the Get to do more seeking than required. Optimize (see HBASE-15392) was causing us to seek all Cells in a block when a Get Scan if the next block index/start key was a different row to the current one. A bug. We'd call next too often because we had to exhaust all Cells in the current row making us load the next block just to discard what we read there. This test is a little cryptic. Takes a bit of staring to figure what it up to.- Throws:
IOException
-
testScanTimeRange
- Throws:
IOException
-
testScanSameTimestamp
- Throws:
IOException
-
testNonUserScan
- Throws:
IOException
-
testWontNextToNext
- Throws:
IOException
-
testDeleteVersionSameTimestamp
- Throws:
IOException
-
testDeletedRowThenGoodRow
- Throws:
IOException
-
testDeleteVersionMaskingMultiplePuts
- Throws:
IOException
-
testDeleteVersionsMixedAndMultipleVersionReturn
- Throws:
IOException
-
testWildCardOneVersionScan
- Throws:
IOException
-
testWildCardScannerUnderDeletes
- Throws:
IOException
-
testDeleteFamily
- Throws:
IOException
-
testDeleteColumn
- Throws:
IOException
-
testSkipColumn
- Throws:
IOException
-
testWildCardTtlScan
- Throws:
IOException
-
testScannerReseekDoesntNPE
- Throws:
Exception
-
testPeek
- Throws:
Exception
-
testExpiredDeleteFamily
Ensure that expired delete family markers don't override valid puts- Throws:
Exception
-
testDeleteMarkerLongevity
- Throws:
Exception
-
testPreadNotEnabledForCompactionStoreScanners
- Throws:
Exception
-
testReadVersionWithRawAndFilter
- Throws:
IOException
-
testScannersClosedWhenCheckingOnlyMemStore
- Throws:
IOException
-