[
https://issues.apache.org/jira/browse/HBASE-10965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971541#comment-13971541
]
stack commented on HBASE-10965:
-------------------------------
bq. Accommodating brokenly implemented filters is already in place.
So the argument is that because we do something whack once, it is ok to
continue along the whack path?
Traditionally, compensations like these compounded makes the rig's operation
fickle.
And this example you cite seems categorically different from your patch in that
it is the internals dictating how execution flows rather than compensation for
what seems like a failure to implement the Interface as described (and that it
calls filterRow though hasFilterRow is false is a bug).
bq. But hasFilterRow() is not defined. There're other files in Phoenix which
exhibit the same pattern.
Eh... file a bug with pheonix that they've failed to implement filters properly.
bq. The contract is clearly published but not all people follow it.
The javadoc is not decisive. That could be tightened up. If folks don't read
the contract, then it makes it tough. We should fail fast though rather than
try make guess at what was intended.
If this issue had examination of why we have these two tied methods at all I'd
have some sympathy for the proposal but as is it looks to me to be making a bad
situation worse.
> Automate detection of presence of Filter#filterRow()
> ----------------------------------------------------
>
> Key: HBASE-10965
> URL: https://issues.apache.org/jira/browse/HBASE-10965
> Project: HBase
> Issue Type: Task
> Reporter: Ted Yu
> Assignee: Ted Yu
> Attachments: 10965-v1.txt, 10965-v2.txt, 10965-v3.txt, 10965-v4.txt
>
>
> There is potential inconsistency between the return value of
> Filter#hasFilterRow() and presence of Filter#filterRow().
> Filters may override Filter#filterRow() while leaving return value of
> Filter#hasFilterRow() being false (inherited from FilterBase).
> Downside to purely depending on hasFilterRow() telling us whether custom
> filter overrides filterRow(List) or filterRow() is that the check below may
> be rendered ineffective:
> {code}
> if (nextKv == KV_LIMIT) {
> if (this.filter != null && filter.hasFilterRow()) {
> throw new IncompatibleFilterException(
> "Filter whose hasFilterRow() returns true is incompatible
> with scan with limit!");
> }
> {code}
> When user forgets to override hasFilterRow(), the above check becomes not
> useful.
> This JIRA aims to remove the inconsistency by automatically detecting the
> presence of overridden Filter#filterRow(). If filterRow() is implemented and
> not inherited from FilterBase, it is equivalent to having hasFilterRow()
> return true.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
