[
https://issues.apache.org/jira/browse/HBASE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591398#action_12591398
]
stack commented on HBASE-584:
-----------------------------
JIm: I'd be fine w/ skipping the usual deprecation in this one case. Apart
from Clint's reasoning above, here's a few more reasons why.
+ In the transition from 0.1 to 0.2, we're breaking the API in a way thats not
backward compatible (HBASE-521); i.e we can't bring users forward using the
usual deprecate because the nature of the changes do not allow it. We can just
slip i these changes under the same umbrella.
+ IMO, I don't think anyone has written Filters (other than maybe Clint
himself) so no one will be effected by the lack of a smooth transition.
> Names in the filter interface are confusing
> -------------------------------------------
>
> Key: HBASE-584
> URL: https://issues.apache.org/jira/browse/HBASE-584
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: filters
> Reporter: Clint Morgan
> Assignee: Clint Morgan
> Priority: Minor
> Attachments: hbase-584.patch
>
>
> I don't like the names of the filter methods in RowFilterInterface. They
> don't really tell how the methods are being used in the implementation of
> scanners.
> I'd like to change:
> - filter(Text) to filterRow(...)
> - filter(Text, Text, byte[]) to filterColumn(...)
> and the worst one is
> - filterNotNull(SortedMap<Text, byte[]>). This should be filterRow(Text,
> SortedMap<Text, byte[]>) (so we add the row key/).
> It may be nice to have timestamps in the methods as well?
> Also the java doc could be cleaned and improved to tell how the filtering is
> implemented (check rows keys first, then check each individual columns,
> finally check the assembled row)
> Upon positive feedback, and I'll create a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
