[
https://issues.apache.org/jira/browse/HBASE-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13966198#comment-13966198
]
Anoop Sam John commented on HBASE-10823:
----------------------------------------
{code}
- Get get = new Get(row);
- if (timestamp != HConstants.LATEST_TIMESTAMP)
get.setTimeStamp(timestamp);
+ Scan scan = new Scan(row);
+ if (timestamp != HConstants.LATEST_TIMESTAMP) {
+ scan.setTimeRange(0, timestamp + 1);
+ } else {
{code}
This change from Get to Scan is to set a TimeRange right Andy? We create scan
with startRow alone? we need
Scan scan = new Scan(row, row) (?)
Also wrt the TS issue which I was thinking, it is bit different than this..
Let me come up with a test to demonstrate that. Will give test later today.
> 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
>
>
> 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)
