[ 
https://issues.apache.org/jira/browse/HBASE-18127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16106385#comment-16106385
 ] 

Abhishek Singh Chouhan commented on HBASE-18127:
------------------------------------------------

> OperationCoprocessorContext could just be called OperationContext?
Sure, will change that.

> Do we need SimpleOperationCoprocessorContext? Will there ever be another kind?
My thinking behind this was that this implementation be used for client 
operations, and some other implementation might be more relevant for admin 
operations/master related operations (balancer switch, shutdown hooks etc. that 
might come up with a similar need as batchMutate in this request) so that the 
coproc can take a decison based on context set by prev hook + other details in 
the OpContext. Can change it to be a class too. Let me know what you think 
[~apurtell] and i'll make the changes.

> Allow regionobserver to optionally skip postPut/postDelete when 
> postBatchMutate was called
> ------------------------------------------------------------------------------------------
>
>                 Key: HBASE-18127
>                 URL: https://issues.apache.org/jira/browse/HBASE-18127
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Lars Hofhansl
>            Assignee: Abhishek Singh Chouhan
>         Attachments: HBASE-18127.master.001.patch
>
>
> Right now a RegionObserver can only statically implement one or the other. In 
> scenarios where we need to work sometimes on the single postPut and 
> postDelete hooks and sometimes on the batchMutate hooks, there is currently 
> no place to convey this information to the single hooks. I.e. the work has 
> been done in the batch, skip the single hooks.
> There are various solutions:
> 1. Allow some state to be passed _per operation_.
> 2. Remove the single hooks and always only call batch hooks (with a default 
> wrapper for the single hooks).
> 3. more?
> [~apurtell], what we had discussed a few days back.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to