[
https://issues.apache.org/jira/browse/HBASE-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497735#comment-13497735
]
Raymond Liu commented on HBASE-6805:
------------------------------------
Gary Helmling and Andrew Purtell : I have try to redesign the code with the
approaching of both Option A and Option B, It turn out that with Option B, to
replace the standard StoreScanner is much more efficient then Option A to
replace the filter. Since in the scanner version, I can decrypt the kv before
send to matcher. thus save the effort needed in pre/postFilterxxx to do raw kv
and real kvs mapping etc. While, just like Gary mentioned, to replace
StoreScanner with say DocStoreScanner, I need to duplicate most part of the
code in it. And actually, I only add a few extra members and modify the next()
method. Also it seems pretty hard to add common enough hooks to perform the
task I need in DocStoreScanner. However, if some of the private member of
StoreScanner could be changed to protected, then I think can subclass
StoreScanner and only override the method I need to tweak into. What's your
opinion on this, do you think to change the private member to protected member
is a feasible approaching? I think if anyone who want to replace the standard
StoreScanner, they will probably encounter the same problem here.
> Extend co-processor framework to provide observers for filter operations
> ------------------------------------------------------------------------
>
> Key: HBASE-6805
> URL: https://issues.apache.org/jira/browse/HBASE-6805
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
> Affects Versions: 0.96.0
> Reporter: Jason Dai
> Attachments: extend_coprocessor.patch
>
>
> There are several filter operations (e.g., filterKeyValue, filterRow,
> transform, etc.) at the region server side that either exclude KVs from the
> returned results, or transform the returned KV. We need to provide observers
> (e.g., preFilterKeyValue and postFilterKeyValue) for these operations in the
> same way as the observers for other data access operations (e.g., preGet and
> postGet). This extension is needed to support DOT (e.g., extracting
> individual fields from the document in the observers before passing them to
> the related filter operations)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
