[
https://issues.apache.org/jira/browse/HBASE-22623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900800#comment-16900800
]
Anoop Sam John commented on HBASE-22623:
----------------------------------------
The CP cleanup was a larger activity. Say some CP API is getting a param type
of HRegion/HStore, possibly it can invoke some methods an get things messy!
Also the BC is another imp aspect. The CPs will have to suffer going from one
version to other as it used some HBase internal APIs. CP used it because we
gave them a clear way for using it. The CP cleanup in 2.0 aimed to shut this
down. (I believe Phoenix is the max suffered because of this internal API
changes)
Seeing the annotation at WALEdit and at the add() methods, it is clear that the
thinking then was to use it in Immutable way.
But in above comment I raised a Q that in existing CP API where we expect to
create a WALEdit and pass it back, there itself how a CP can do that with a
private exposed API been used. So ya either we should remove that private
annotation or should give a Factory way of create WALEdit (For the existing
usage itself)
> Add RegionObserver coprocessor hook for preWALAppend
> ----------------------------------------------------
>
> Key: HBASE-22623
> URL: https://issues.apache.org/jira/browse/HBASE-22623
> Project: HBase
> Issue Type: New Feature
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
>
> While many coprocessor hooks expose the WALEdit to implementing coprocs,
> there aren't any that expose the WALKey before it's created and added to the
> WALEntry.
> It's sometimes useful for coprocessors to be able to edit the WALKey, for
> example to add extended attributes using the fields to be added in
> HBASE-22622.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
