[
https://issues.apache.org/jira/browse/HBASE-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-3170:
--------------------------
Attachment: 3170-v2.patch
It turns out that we need to keep the original behavior of Scan.isGetScan()
Patch v2 introduced two new fields for RegionScannerImpl and made the logic in
isStopRowConsideringEmptyRows() symmetrical.
The following tests passed:
1430 mt -Dtest=TestScanWithBloomError,TestStoreFile,TestGetEmptyRowKey
1433 mt -Dtest=TestHRegion,TestColumnSeeking,TestMultiColumnScanner
> RegionServer confused about empty row keys
> ------------------------------------------
>
> Key: HBASE-3170
> URL: https://issues.apache.org/jira/browse/HBASE-3170
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.89.20100621, 0.89.20100924, 0.90.0, 0.90.1, 0.90.2,
> 0.90.3, 0.90.4, 0.90.5, 0.90.6, 0.92.0, 0.92.1
> Reporter: Benoit Sigoure
> Assignee: Devaraj Das
> Priority: Critical
> Fix For: 0.96.0
>
> Attachments: 3170-1.patch, 3170-v2.patch
>
>
> I'm no longer sure about the expected behavior when using an empty row key
> (e.g. a 0-byte long byte array). I assumed that this was a legitimate row
> key, just like having an empty column qualifier is allowed. But it seems
> that the RegionServer considers the empty row key to be whatever the first
> row key is.
> {code}
> Version: 0.89.20100830, r0da2890b242584a8a5648d83532742ca7243346b, Sat Sep 18
> 15:30:09 PDT 2010
> hbase(main):001:0> scan 'tsdb-uid', {LIMIT => 1}
> ROW COLUMN+CELL
>
> \x00 column=id:metrics, timestamp=1288375187699,
> value=foo
> \x00 column=id:tagk, timestamp=1287522021046,
> value=bar
> \x00 column=id:tagv, timestamp=1288111387685,
> value=qux
> 1 row(s) in 0.4610 seconds
> hbase(main):002:0> get 'tsdb-uid', ''
> COLUMN CELL
>
> id:metrics timestamp=1288375187699, value=foo
>
> id:tagk timestamp=1287522021046, value=bar
>
> id:tagv timestamp=1288111387685, value=qux
>
> 3 row(s) in 0.0910 seconds
> hbase(main):003:0> get 'tsdb-uid', "\000"
> COLUMN CELL
>
> id:metrics timestamp=1288375187699, value=foo
>
> id:tagk timestamp=1287522021046, value=bar
>
> id:tagv timestamp=1288111387685, value=qux
>
> 3 row(s) in 0.0550 seconds
> {code}
> This isn't a parsing problem with the command-line of the shell. I can
> reproduce this behavior both with plain Java code and with my asynchbase
> client.
> Since I don't actually have a row with an empty row key, I expected that the
> first {{get}} would return nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
