[
https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967008#comment-13967008
]
Anoop Sam John commented on HBASE-10823:
----------------------------------------
Oh Sorry Andy.. I was trying to pass the new test.
bq.Anoop Sam John do you think the latest patch here is sufficient for now?
With considering the last cell's TS...!! hmm I doubt...
In the same test which I attached, we can have like
{code}
Delete d = new Delete(TEST_ROW1);
d.deleteColumns(TEST_FAMILY, TEST_Q2, 124L);
d.deleteColumns(TEST_FAMILY, TEST_Q1, 127L);
{code}
such that for Q1 we may have to check for 2 cells acl but for Q2 only 1 cell's.
> 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)
