[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030338#comment-14030338
]
ramkrishna.s.vasudevan commented on HBASE-10885:
------------------------------------------------
bq.then we need to check if the effective auths of the user who issued the
delete grant visibility to the covered cell. Only if true do we delete it.
Oh.. Then this becomes more complex. So not only the cell visibility
associated with the delete needs to be considered, in cases that is not present
then go with the Auths defined in the labels table? In that sense I feel
passing Cell visibility itself is not needed right? Apply deletes only based
on the Auths associated with the user issuing the delete. Also if this
behaviour we need not only we need to match the exact labels but also do as in
Scan and find out if the labels in the cell is a subset of the auths and then
decide the delete behaviour.
bq.#2 is the semantic change from earlier versions.
I agree that we can change the semantics without which we are not allowing the
deletes to function properly.
I was testing more scenarios today and ended up in more tricky situations
{code}
put 't1','r1','f1:c1','100',101,{VISIBILITY=>'PRIVATE|SECRET'}
put 't1','r1','f1:c1','100',102,{VISIBILITY=>'PRIVATE'}
put
't1','r1','f1:c1','100',103,{VISIBILITY=>'(SECRET&TOPSECRET)|(PRIVATE&CONFIDENTIAL)'}
put 't1','r1','f1:c1','100',104,{VISIBILITY=>'(SECRET&TOPSECRET)'}
put
't1','r1','f1:c1','100',105,{VISIBILITY=>'(SECRET&TOPSECRET)|(PRIVATE&CONFIDENTIAL)'}
{code}
Now issue these two deletes
{code}
delete_column_timeStamp 't1','r1','f1:c1',104,'SECRET&TOPSECRET'
delete_familyversion
't1','r1','f1:c1',103,'(CONFIDENTIAL&PRIVATE)|(TOPSECRET&SECRET)'
{code}
Now when we do
{code}
delete_family 't1','r1','f1','PRIVATE|SECRET'
{code}
Then we are bound to get back all the previously deleted cells also as per the
current patch because DELETE_FAMILY being a higher precedence we don check for
lower types of deletes and only match the visibility labels for those cells
with PRIVATE|SECRET and this makes already deleted cells to reappear.
> 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: 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
>
>
> 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)
