[
https://issues.apache.org/jira/browse/HBASE-9331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749833#comment-13749833
]
Vasu Mariyala commented on HBASE-9331:
--------------------------------------
[~yuzhih...@gmail.com] Does FuzzyRowFilter have the below assumptions?
a) All the row keys are off the same length because the next for a valid fuzzy
row match (key={0,1,1,1}) can always be a zero appended byte array
(key={0,1,1,1,0}). If this assumption is always true, this jira could no longer
be an issue.
b) The length of the row key must always be greater than or equal to the length
of fuzzy row key or fuzzy info.
{code}
Assert.assertEquals(FuzzyRowFilter.SatisfiesCode.YES,
FuzzyRowFilter.satisfies(new byte[]{1, 0, 1}, // row to check only 3
bytes
new byte[]{1, 0, 1, 0, 1}, // fuzzy row
contains 5 bytes
new byte[]{0, 1, 0, 0, 0})); // mask contains
5 bytes
The intention is to extract the rows off the pattern 1?101. But a row 101
satisfies the pattern and is included in the results.
{code}
c) Does fuzzy row key need to have '0's even in the places where the fuzzy info
contains a 1 (indicates a non-fixed byte)
{code}
assertNext(
new byte[]{1, 1, 1, 1}, //fuzzy row
new byte[]{0, 0, 1, 1}, //fuzzy mask (info)
new byte[]{0, 1, 3, 2}, //current row
new byte[]{1, 1, 1, 1}); //next row (expected). FAILURE: There is a
potential match at {1,1,0,0} and has been ignored by the FuzzyRowFilter.
{code}
> FuzzyRow filter getNextForFuzzyRule not working properly for special case
> -------------------------------------------------------------------------
>
> Key: HBASE-9331
> URL: https://issues.apache.org/jira/browse/HBASE-9331
> Project: HBase
> Issue Type: Bug
> Components: Filters
> Affects Versions: 0.94.11
> Environment: Issue is not dependent upon environment.
> Reporter: Tony Dean
> Attachments: TestFuzzyRowFilter.patch
>
>
> The case that getNextForFuzzyRule() fails is when the result (fuzzy key) is
> extended in length (zero padded) to match the current row for comparisons.
> If the hint is returned with zero padded bytes, the next seek may skip over a
> valid match. See the example below.
> /**
> * The code below circumvents the following situation.
> *
> * fuzzy.key = visitor,session,Logon
> * fuzzy.mask = 000000001111111000000
> *
> * example hbase row data:
> * visitor,session,AddToCart
> * " " FacebookLike
> * " " Logon
> * " " MobileSpecial
> * ...
> *
> *
> * For row "visitor,sessionAddToCart", the current code would
> * return a hint of "visitor,session,Logon\0\0\0\0" (zero padded).
> * The next seek would skip "visitor,session,Logon" and jump
> * to "visitor,session,MobileSpecial".
> */
>
> // trim trailing zeros that were not part of the original fuzzy key
> int i = result.length;
> for (; i > fuzzyKeyBytes.length; i--)
> {
> if (result[i-1] != 0x00)
> break;
> }
> if (i != result.length)
> {
> result = Arrays.copyOf(result, i);
> }
> The code above added to the end of getNextFuzzyRule() will circumvent the
> issue. I tested my scenario and it produces the correct results. There may
> be a better solution.
> Thanks.
--
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
