[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872936#comment-16872936
]
stack commented on HBASE-22622:
-------------------------------
[~gjacoby] A few notes sir:
* In hbase2, IIRC, we did our best to purge access to protobufs from CP API so
we could evolve our pb schemas and versions internally w/o breaking thirdparty
CPs. E.g. at head of WALEdit class it has a note '// TODO: Do not expose this
class to Coprocessors. It has set methods. A CP might meddle.' This would seem
to preclude giving a CP access to a pb map as you suggest above.
* Which particular CP APIs were you hoping to intercept (in branch-2?)? That'd
help concentrate this discussion I think.
* Cells on the server-side can have arbitrary tags. Not as nice as a single
piece of metadata on a WALEdit and this probably doesn't suit your needs but
putting it out there.
Thanks
> WALKey Extended Attributes
> --------------------------
>
> Key: HBASE-22622
> URL: https://issues.apache.org/jira/browse/HBASE-22622
> Project: HBase
> Issue Type: New Feature
> Components: wal
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Major
>
> It would be useful if the WAL protobuf and WALKey class included an optional
> map of extended key/value attributes that downstream coprocessors could use
> to annotate WAL Entries. While standard HBase replication would not use them,
> custom replication endpoints could use the data to make filtering decisions
> or take actions.
> An example use case would be allowing a tool like Phoenix to annotate
> WAL.Entries to indicate that a given Entry is associated with a particular
> Phoenix view rather than the base Phoenix table. (Multiple logical views in
> Phoenix can map to the same physical HBase table.) A custom replication
> endpoint might choose to replicate some views but not others.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
