[
https://issues.apache.org/jira/browse/HBASE-22623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901262#comment-16901262
]
Andrew Purtell edited comment on HBASE-22623 at 8/6/19 5:12 PM:
----------------------------------------------------------------
The explicit intent of the new hook is to modify or decorate the objects going
into the WAL. That is at least WALKey, but a WAL entry is built from two
objects: the WALKey, and the WALEdit. The hook should address both, otherwise
we are leaving an obvious gap. We have been in a position before where CP hooks
needed to be modified because they didn't quite expose what was necessary for
the CP application to modify or replace in order to achieve its aim. I think we
can avoid a fairly obvious gap here.
The second question is why a WALEdit is immutable. My guess is it is only
because there has never been a need to modify one after construction.
We don't need to change WALEdit, but one of the parameters of this hook should
carry the WALEdit, if only to make its state visible to the coprocessor. That
said, I have no objection to removing the annotation from WALEdit's add method.
Coprocessors should be able to change state in the agreed upon scope.
In this issue I see us trying to build consensus that WALKey and WALEdit are
useful inputs to a coprocessor which wants to decorate a WAL entry just before
commit. There is a real use case for this in Phoenix. (Change capture device.)
Unless there is an objection I think we have that consensus per the three way
conversation between Geoffrey, Anoop, and myself.
Edit: If we agree to do this, then let us also annotate WALKey and WALEdit as
LP(Coproc)
was (Author: apurtell):
The explicit intent of the new hook is to modify or decorate the objects going
into the WAL. That is at least WALKey, but a WAL entry is built from two
objects: the WALKey, and the WALEdit. The hook should address both, otherwise
we are leaving an obvious gap. We have been in a position before where CP hooks
needed to be modified because they didn't quite expose what was necessary for
the CP application to modify or replace in order to achieve its aim. I think we
can avoid a fairly obvious gap here.
The second question is why a WALEdit is immutable. My guess is it is only
because there has never been a need to modify one after construction.
We don't need to change WALEdit, but one of the parameters of this hook should
carry the WALEdit, if only to make its state visible to the coprocessor. That
said, I have no objection to removing the annotation from WALEdit's add method.
Coprocessors should be able to change state in the agreed upon scope.
In this issue I see us trying to build consensus that WALKey and WALEdit are
useful inputs to a coprocessor which wants to decorate a WAL entry just before
commit. There is a real use case for this in Phoenix. (Change capture device.)
Unless there is an objection I think we have that consensus per the three way
conversation between Geoffrey, Anoop, and myself.
> 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)
