hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-10823) Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
Date Fri, 11 Apr 2014 21:18:16 GMT

    [ https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967090#comment-13967090
] 

Andrew Purtell edited comment on HBASE-10823 at 4/11/14 9:17 PM:
-----------------------------------------------------------------

bq. With considering the last cell's TS...!! 

No that's not it. We issue one Get to find the covered cells, and we want to put a timerange
on it. Timerange does not allow discontinuities, and gets do not allow a timerange per family
or family:qualifer. So we find the latest timestamp either specified by the op or one of the
cells therein and go with that. I think that is fine for now. We may have to resort to a custom
filter ultimately. 

We have to make a decision about the entire Delete op, minimizing overheads incurred while
doing so. As long as we are not allowing something we shouldn't, any usability issues that
come up because we find more cells than are truly covered by a tombstone, are mitigated by
the client still being able to structure the deletes they want to accomplish in separate operations.
So unless objection I am going to commit this patch as better than what we have now, unless
you are thinking of a logic bug that allows something we shouldn't. Then let's look at a test
case for that. 


was (Author: apurtell):
bq. With considering the last cell's TS...!! 

No that's not it. We issue one Get to find the covered cells, and we want to put a timerange
on it. Timerange does not allow discontinuities, and gets do not allow a timerange per family
or family:qualifer. So we find the latest timestamp either specified by the op or one of the
cells therein and go with that. I think that is fine for now. We may have to resort to a custom
filter ultimately. 

We are making a decision about the entire Delete op, and as long as we are not allowing something
we shouldn't, any usability concerns are mitigated by just issuing multiple Deletes separately.
So unless objection I am going to commit this patch as better than what we have now, unless
you are thinking of a logic bug that allows something we shouldn't. Then let's look at a test
case for that. 

> Resolve LATEST_TIMESTAMP to current server time before scanning for ACLs
> ------------------------------------------------------------------------
>
>                 Key: HBASE-10823
>                 URL: https://issues.apache.org/jira/browse/HBASE-10823
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.98.1
>            Reporter: Andrew Purtell
>            Assignee: Andrew Purtell
>            Priority: Minor
>             Fix For: 0.99.0, 0.98.2
>
>         Attachments: HBASE-10823.patch, HBASE-10823.patch, HBASE-10823.patch, test.patch
>
>
> Storing values with timestamps in the future is probably bad practice and can lead to
surprises. If cells with timestamps in the future have ACLs, permissions from those ACLs will
incorrectly be considered for authorizing the pending mutation. For sure that will be surprising.
> We should be able to avoid this case by resolving LATEST_TIMESTAMP to the current server
time when creating the internal scanner for finding ACLs in the covered cell set. 
> Documenting a todo item from a discussion between [~anoop.hbase] and myself.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message