[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045505#comment-14045505
]
Anoop Sam John commented on HBASE-10885:
----------------------------------------
bq.One round of review on the VisisbilityDeleteTracker would be great before
committing this.
Good testing Ram. U found the missing scenario we missed in reviews also..
Looking at this VisisbilityDeleteTracker I think still need changes.
I think for every delete type u have to track TS vs vis exp.
In normal case, for family delete, the latest TS only we need to track and
delete all under that TS.
Now with vis exp also in place, the combination of TS + vis exp us becoming
something based on which the decision of whether cell is deleted or not is
calculated.
So in this tracking if same family comes and vis exp is different you have to
track that TS vs vis exp. And if again same family comes wih same as previous
vis exp, just ignore (As the second one TS will be lower. We need consider the
higher TS value)
Similar way for all types we will need track.
Things are bit complex :)
> Support visibility expressions on Deletes
> -----------------------------------------
>
> Key: HBASE-10885
> URL: https://issues.apache.org/jira/browse/HBASE-10885
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.98.1
> Reporter: Andrew Purtell
> Assignee: ramkrishna.s.vasudevan
> Priority: Blocker
> Fix For: 0.99.0, 0.98.4
>
> Attachments:
> 10885-org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithDeletes-output.txt,
> HBASE-10885_1.patch, HBASE-10885_2.patch, HBASE-10885_new_tag_type_1.patch,
> HBASE-10885_new_tag_type_2.patch, HBASE-10885_v1.patch, HBASE-10885_v2.patch,
> HBASE-10885_v2.patch, HBASE-10885_v2.patch, HBASE-10885_v3.patch,
> HBASE-10885_v4.patch, HBASE-10885_v5.patch, HBASE-10885_v7.patch,
> HBASE-10885_v8.patch, HBASE-10885_v9.patch
>
>
> Accumulo can specify visibility expressions for delete markers. During
> compaction the cells covered by the tombstone are determined in part by
> matching the visibility expression. This is useful for the use case of data
> set coalescing, where entries from multiple data sets carrying different
> labels are combined into one common large table. Later, a subset of entries
> can be conveniently removed using visibility expressions.
> Currently doing the same in HBase would only be possible with a custom
> coprocessor. Otherwise, a Delete will affect all cells covered by the
> tombstone regardless of any visibility expression scoping. This is correct
> behavior in that no data spill is possible, but certainly could be
> surprising, and is only meant to be transitional. We decided not to support
> visibility expressions on Deletes to control the complexity of the initial
> implementation.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
