You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2008/09/25 15:03:44 UTC

[jira] Commented: (HBASE-786) Subclass of TableMap which accepts a date range to be applied to timestamps

    [ https://issues.apache.org/jira/browse/HBASE-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634476#action_12634476 ] 

Andrew Purtell commented on HBASE-786:
--------------------------------------

Instead of many and varied subclasses of Table Map (which I can see occurring...) how about updates to TableInputFormat and TableMap.initJob() that support specifying filters for input tables, and an update to ColumnValueFilter that allows specification of timestamp ops?

Then the intent of this issue could be handled by:

{code}
Set<RowFilterInterface> set = new HashSet<RowFilterInterface>();
set.add(new ColumnValueFilter(..., ColumnValueFilter.CompareOp.TIMESTAMP_GREATER_OR_EQUAL,...);
set.add(new ColumnValueFilter(..., ColumnValueFilter.CompareOp.TIMESTAMP_LESS, ...);
RowFilterSet filterSet = new RowFilterSet(..., set);
TableMap.initJob(..., filterSet);
{code}

What do you think?


> Subclass of TableMap which accepts a date range to be applied to timestamps
> ---------------------------------------------------------------------------
>
>                 Key: HBASE-786
>                 URL: https://issues.apache.org/jira/browse/HBASE-786
>             Project: Hadoop HBase
>          Issue Type: New Feature
>            Reporter: Adam Gerber
>            Priority: Minor
>
> There would exist a TableMap subclass which load only those records whose timestamp is within the specified range.
> The date range could be accessible via the initJob method, which would accept start date and end date as parameters.
> If either parameter is null, the range could be considered unbounded in that direction.
> Such a class could either receive each "version" as a different input, or it could receive arrays of those "versions" as input - 
> perhaps two classes would exist, covering both approaches.
> Keeping versions together could be helpful in saving the designer from having to reconstitute this structure (to answer questions
> such as "how many versions does the average record have?")

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.