[
https://issues.apache.org/jira/browse/HBASE-22623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903233#comment-16903233
]
Andrew Purtell commented on HBASE-22623:
----------------------------------------
I am merging the current PR and [~gjacoby] has indicated a backport patch to
branch-1 is forthcoming, which I will wait for. I'll pick to the branch-2, that
looks straightforward. Let me repeat some comments I left on the PR here
because it is a PMC level issue that should be addressed I think. Getting
visibility:
The new method is not going to be deprecated out of the bat. (I agree with
[~gjacoby] this is nonsensical and the conversation here is getting more
confusing because of an underlying misalignment IMHO).
We are not monolithic in our approach (and hostility) to coprocessor interfaces
as a community. Imposing that disagreement on contributors is not appropriate.
I am going to merge this as is and we can follow up on what should or should
not be deprecated as a larger conversation on the future of coprocessors. The
community has some big disagreements in approach.
I also agree the "policy", such as it is, is contradictory and confusing. We
need to attack the bigger picture on dev@ in a discussion about the future of
coprocessors and our tolerance (or not) to the requests of the Phoenix project.
The opinions are not monolithic. There are some supporters, there are some
hostile positions, both are valid in my view, we need to sort out the
disagreement. This issue isn't the right scope for that. The contradictory
positions are evident in the tug and pull of the suggestions to the contributor.
> 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)
