[ 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)