[
https://issues.apache.org/jira/browse/HBASE-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555714#comment-13555714
]
Todd Lipcon commented on HBASE-7387:
------------------------------------
But if they're private implementation details, then you should expect that they
might change (eg we might find a new optimization or restructure the internals
of the scanner). Then your coprocessor would break, whereas if you duplicated
the logic (perhaps by sharing various utility code), it would be less fragile.
I havent looked at the CP hook recently -- do you have to provide a
StoreScanner, or is there an upper level interface that you need to share?
What's the shared functionality between your "entirely different approach"
scanner and the usual implementation?
> StoreScanner need to be able to be subclassed
> ---------------------------------------------
>
> Key: HBASE-7387
> URL: https://issues.apache.org/jira/browse/HBASE-7387
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Affects Versions: 0.96.0
> Reporter: Raymond Liu
> Assignee: Raymond Liu
> Priority: Minor
> Fix For: 0.96.0
>
> Attachments: HBASE_7387_v2.patch, StoreScanner.patch
>
>
> StoreScanner can be replaced by preStoreScannerOpen hook with CP. In order to
> reuse most of the logic in current StoreScanner, subclass it might be the
> best approaching. Thus a lot of private member need to be changed from
> private to protected.
> At present, in order to to implement a custom storescanner for dot
> (HBASE-6805), only a few of the private member need to be changed as in the
> attached storescanner.patch, while should we change all the reasonable field
> from private to protected as in HBASE-7387-v?.patch
--
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
