Class TestStoreScanner
java.lang.Object
org.apache.hadoop.hbase.regionserver.TestStoreScanner
-
Nested Class Summary
Nested ClassesModifier and TypeClassDescriptionprivate static classA StoreScanner for our CELL_GRID above.private static classprivate static classprivate static class -
Field Summary
FieldsModifier and TypeFieldDescriptionprivate static final org.apache.hadoop.hbase.ExtendedCell[]Five rows by four columns distinguished by column qualifier (column qualifier is one of the four rows...private static final intprivate static final intprivate static final intprivate static final intprivate static final org.apache.hadoop.hbase.ExtendedCell[]private static final intprivate static final byte[]private static final Stringstatic final HBaseClassTestRule(package private) static org.apache.hadoop.conf.Configurationprivate static final byte[]private static final byte[]private static final org.apache.hadoop.hbase.KeyValue[]private static final org.slf4j.Loggerorg.junit.rules.TestNameprivate static final byte[]private org.apache.hadoop.hbase.regionserver.ScanInfoprivate static final HBaseTestingUtilprivate 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
Constructors -
Method Summary
Modifier and TypeMethodDescription(package private) NavigableSet<byte[]>voidvoidvoidvoidvoidvoidvoidvoidEnsure that expired delete family markers don't override valid putsvoidvoidvoidvoidTest optimize in StoreScanner.voidEnsure the optimize Scan method in StoreScanner does not get in the way of a Get doing minimum work...voidEnsure that optimize does not cause the Get to do more seeking than required.voidtestPeek()voidvoidvoidvoidvoidvoidvoidvoidvoidvoidvoidvoid
-
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 theStoreScanneris 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
-