[
https://issues.apache.org/jira/browse/HBASE-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885763#action_12885763
]
Kannan Muthukkaruppan commented on HBASE-2793:
----------------------------------------------
I am going to revise the diff after discussion with Jonathan.
Currently, on the server side, I was special casing by looking to see if the
filter is an instanceof TimestampsFilter and then updating/narrowing down the
timerange based on that. But the special casing will not quite work if for
example it is compound filter.
-----
Another question: Both ScanQueryMatcher and QueryMatcher have filter logic--
but they seem to be doing different things in the fallthrough/default case.
In ScanQueryMatcher:
{code}
if (filterResponse == ReturnCode.INCLUDE)
return MatchCode.INCLUDE;
if (filterResponse == ReturnCode.SKIP)
return MatchCode.SKIP;
// else if (filterResponse == ReturnCode.NEXT_ROW)
stickyNextRow = true;
return MatchCode.SEEK_NEXT_ROW;
{code}
the default behavior is MatchCode.SEEK_NEXT_ROW;
In QueryMatcher:
{code}
if (mc == MatchCode.INCLUDE && this.filter != null) {
switch(this.filter.filterKeyValue(kv)) {
case INCLUDE: return MatchCode.INCLUDE;
case SKIP: return MatchCode.SKIP;
default: return MatchCode.DONE;
}
}
{code}
the default case is MatchCode.DONE
I am not clear on the why the above difference. Any ideas?
For the timestamps filter, which now (with my change) returns a new code
Filter.NEXT_COL (when the scan falls below the min timestamp), I guess I need
to update both of these places. Currently, my patch only does this in
ScanQueryMatcher.
> Add ability to extract a specified list of versions of a column in a single
> roundtrip
> -------------------------------------------------------------------------------------
>
> Key: HBASE-2793
> URL: https://issues.apache.org/jira/browse/HBASE-2793
> Project: HBase
> Issue Type: New Feature
> Reporter: Kannan Muthukkaruppan
> Assignee: Kannan Muthukkaruppan
> Attachments: 2793_patch_v1.txt
>
>
> In one of the use cases we were looking at, each row contains a single
> column, but with several versions (e.g., each version representing an event
> in a log), and we want to be able to extract specific set of versions from
> the row in a single round-trip.
> Currently, on a Get, one can retrieve a specific version of a column using
> setTimeStamp(ts) or a range of versions using setTimeRange(min, max). But not
> a set of specified versions. It would be useful to add this ability.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.