[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872590#comment-16872590
]
Geoffrey Jacoby commented on HBASE-22622:
-----------------------------------------
[~Apache9], thanks for the suggestions, but unfortunately that wouldn't work.
First thing, it would be user-unfriendly to insist that the end-users follow a
particular naming convention when naming their views or tables. 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.
And I haven't even gotten into multi-tenancy, where different tenants each get
their own namespace and can create their own views and indexes whose names
might clash with ones owned by other tenants. Figuring this stuff out with
purely HBase-level APIs ranges from difficult to impossible.
So, to sum up, since it's easy to get into the weeds:
1. The Phoenix schema model is really complicated.
2. There are Phoenix APIs that help manage the complexity.
3. Those APIs require parameters (like logical table/view name) that aren't
available in a WALKey or WALEdit, and others like tenantId that are only
available doing really ugly parsing of row keys in the WALEdit
4. Letting Phoenix annotate the missing schema info into a WALKey would let us
do many nice things we can't do now.
> 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)
