[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872855#comment-16872855
]
Duo Zhang commented on HBASE-22622:
-----------------------------------
{quote}
Second thing, even if we did enforce such a naming convention, we would still
need this JIRA, because in the replication endpoint we wouldn't know the name
of the view anyway from the WALKey without Phoenix annotating extended
attributes.
{quote}
I do not fully understand I'd say, why in replication endpoint we wouldn't know
the name of the view? It is not a special table? And if you choose to write the
data into the same region, then how do you filter out these values when
scanning the table? If you filter it out when scanning, then why you can not
filter it out in replication endpoint?
> 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)
