[
https://issues.apache.org/jira/browse/HBASE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591378#action_12591378
]
Clint Morgan commented on HBASE-584:
------------------------------------
I get that, but does the policy make sense for interfaces that are only exposed
for users to implement (rather than use)?
Two cases here:
- User is simply using the filters. Then he only touches the constructors, and
interface changes will not matter to him.
-User has implemented their own RowFilter. But then they will still get
compile error either way because they do not have the new interface names. If
they were all inheriting from an AbstractRowFilter or something, then we could
make it work, but otherwise I don't see the point of the @deprecation.
What am I missing?
> 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.
