[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873602#comment-16873602
]
stack commented on HBASE-22622:
-------------------------------
Thanks [~gjacoby] for detail (Sorry, I missed the associated issue. We could
group them via parent and sub-issues?).
A few other comments:
* Yeah. CPs can't have access to hbase pbs. It'll hamper the CP evolution as
well as hbase's ability to move forward its internals.
* Does Phoenix field replication streams currently or is it to be added? I ask
because intercepting replication stream has been brittle/poorly supported with
non-public APIs up to this in need of a cleanup. The lily indexer used to make
use of what replication API existed but work was done to move its intercession
up and out on to public APIs around hbase2.0.
* I appreciate Andrew's weeding of the WAL* objects. A note in WALKeyImpl
suggests WALKey should go away since it only ever processed when a WALedit is
to hand... but addressing this is a separate issue.
* A generic means of adding metadata payload on a WALEdit could be a nice
addition if no cost incurred if facility goes unused. That said, throwing out
other notions that you've probably considered already and are likely inadequate
but that might make for a less disruptive change:
** it is not possible to add a marker Cell into a WALEdit, one that carries
the meta info? E.g. the last in the pack so easy to find? We could a Cell type
that describes it as not-for-persistence.
** We already have a set of special WALEdit types to mark bulk load events,
compactions, etc. Could this mechanism be used to pass metadata for Phoenix?
** TableName is made of namespace and table name. Encode metadata here?
Is this for branch-1 or branch-2 or master?
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)
