[
https://issues.apache.org/jira/browse/HBASE-7663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815107#comment-13815107
]
Andrew Purtell commented on HBASE-7663:
---------------------------------------
bq. Should we have an Interface that is other-than-Mutation that Scan and Get
implement (and Increment i suppose since it retturns a value)?
I have the same issue over on the cell ACL patch, I need to duplicate these
convenience getters and setters in Get, Mutation, and Scan. It would be good to
have a common interface or base class for Scan and Get, maybe 'Query' (for
symmetry with Mutation)? I have fun in places receiving OperationWithAttributes
and then downcasting, that would go away.
> [Per-KV security] Visibility labels
> -----------------------------------
>
> Key: HBASE-7663
> URL: https://issues.apache.org/jira/browse/HBASE-7663
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors, security
> Affects Versions: 0.98.0
> Reporter: Andrew Purtell
> Assignee: Anoop Sam John
> Fix For: 0.98.0
>
> Attachments: HBASE-7663.patch, HBASE-7663_V2.patch,
> HBASE-7663_V3.patch, HBASE-7663_V4.patch, HBASE-7663_V5.patch,
> HBASE-7663_V6.patch
>
>
> Implement Accumulo-style visibility labels. Consider the following design
> principles:
> - Coprocessor based implementation
> - Minimal to no changes to core code
> - Use KeyValue tags (HBASE-7448) to carry labels
> - Use OperationWithAttributes# {get,set}Attribute for handling visibility
> labels in the API
> - Implement a new filter for evaluating visibility labels as KVs are streamed
> through.
> This approach would be consistent in deployment and API details with other
> per-KV security work, supporting environments where they might be both be
> employed, even stacked on some tables.
> See the parent issue for more discussion.
--
This message was sent by Atlassian JIRA
(v6.1#6144)