[
https://issues.apache.org/jira/browse/HBASE-22623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900145#comment-16900145
]
Geoffrey Jacoby commented on HBASE-22623:
-----------------------------------------
So, I see that the immutability of the Region-created WALEdit is an explicit
goal of the current code, but what I'm trying to understand is _why_.
Immutability can be a wonderful thing; it lets you write idempotent code along
functional principles where code has no side effects, just an output. But it
seems to me the entire point of coprocessors _is to have side effects_.
I'm sure we could come up with an indirect way to accomplish the adding of
cells -- maybe something like WALEdit preWALAppend(WALKey,
WALEditSuperInterfaceWithoutAddMethods edit), where HRegion then takes the
returned new WALEdit and combines its Cells with the Cells of the existing
WALEdit -- but I don't see what the added complexity achieves. It would just be
more object churn for the garbage collector.
> 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)
