[ 
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan updated HBASE-10885:
-------------------------------------------

    Attachment: HBASE-10885_1.patch

First version for review.  Once shell support is committed in the sub-task this 
patch could be easily tested from shell also.
Tried out the option of using VisiblityDeleteFilters also, but it has some code 
duplication required and all the scan should be of type raw (incase of user 
scan and compaction).  So we may have to lose the information if the scan has 
already been attached with the families and qualifiers that needs to be 
retrieved.

> 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: Critical
>             Fix For: 0.99.0, 0.98.2
>
>         Attachments: HBASE-10885_1.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)

Reply via email to