[
https://issues.apache.org/jira/browse/HBASE-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770388#comment-13770388
]
Liang Xie commented on HBASE-9559:
----------------------------------
Just found those comments before getRowKeyAtOrBefore() :
{code}
* Find the key that matches <i>row</i> exactly, or the one that immediately
* precedes it. WARNING: Only use this method on a table where writes occur
* with strictly increasing timestamps. This method assumes this pattern of
* writes in order to make it reasonably performant. Also our search is
* dependent on the axiom that deletes are for cells that are in the container
* that follows whether a memstore snapshot or a storefile, not for the
* current container: i.e. we'll see deletes before we come across cells we
* are to delete. Presumption is that the memstore#kvset is processed before
* memstore#snapshot and so on.
{code}
> getRowKeyAtOrBefore may be incorrect for some cases
> ---------------------------------------------------
>
> Key: HBASE-9559
> URL: https://issues.apache.org/jira/browse/HBASE-9559
> Project: HBase
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Priority: Minor
>
> See also HBASE-9503. Unless I'm missing something, getRowKeyAtOrBefore does
> not handle cross-file deletes correctly. It also doesn't handle timestamps
> between two candidates of the same row if they are in different file (latest
> by ts is going to be returned).
> It is only used for meta, so it might be working due to low update rate, lack
> of anomalies and the fact that row values in meta are reasonably persistent,
> new ones are only added in split.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
