Geoffrey Jacoby commented on HBASE-22623:

[~Apache9] - any coprocessor hook can create data loss if used maliciously or 
incorrectly, because they allow arbitrary code execution; I gave examples 
above. But to turn back to the patch...

I definitely see your and [~anoop.hbase]'s point about the meta cell addition. 
Making the coproc authors need to know about low level HBase details like that 
would make it easy to make mistakes and require boilerplate code in almost 
every hook implementation. I will incorporate that into the patch.

But WALEdit isn't some strange, exotic class that's never been exposed to 
client developers. WAL.Entry, WALKey, and WALEdit are already part of the 
WALEntryFilter / ReplicationEndpoint API, which I've worked with wearing both 
my Phoenix and day-job hats. I can already add a Cell to a Put through a 
coproc, and I can add a Cell to the WALEdit bound for a _remote_ cluster by a 
custom replication endpoint. Other coproc hooks after the WAL sync expose the 
WALEdit too. 

The fact that I have existing cumbersome ways to accomplish this isn't a reason 
not to give me a straightforward one, but the opposite. It's most often when 
developers try to do cumbersome workarounds that we get into trouble. :-)

> 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

Reply via email to