You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Junegunn Choi (JIRA)" <ji...@apache.org> on 2016/06/28 09:05:57 UTC

[jira] [Commented] (HBASE-16106) HBase Rest API: unexpected behavior of get with timestamp

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

Junegunn Choi commented on HBASE-16106:
---------------------------------------

{{Scan}} and {{Get}} of HBase client API provide two methods for specifying timestamps. One is {{setTimeRange}} where you specify min and max timestamps (inclusive and exclusive respectively), and the other is {{setTimestamp}} which is for fetching data for a single timestamp value.

You expected the REST server to use the latter, but it currently interprets {{/TS}} as the range {{[0, TS)}} and calls {{setTimeRange}} accordingly. Since the max timestamp is exclusive, you're not getting the value with the timestamp. As suggested in the link, you can retrieve the value with {{/TS+1}}, but then the result set can include values with older timestamps, so technically, it should be {{/TS,TS+1}}.

I can't tell if this behavior is intentional (bug or feature?), but I also think that it can be confusing and the documentation is lacking.

> HBase Rest API: unexpected behavior of get with timestamp
> ---------------------------------------------------------
>
>                 Key: HBASE-16106
>                 URL: https://issues.apache.org/jira/browse/HBASE-16106
>             Project: HBase
>          Issue Type: Bug
>          Components: API, REST
>    Affects Versions: 1.2.1
>            Reporter: Blaye Nicolas
>            Priority: Minor
>              Labels: easyfix, newbie
>
> Issue seen there: http://stackoverflow.com/questions/37985426/hbase-get-request-for-row-data-with-timestamp?noredirect=1#comment63464266_37985426  
> The  *adress:port/table/row/column/timestamp* returns the first value *strictly inferior* to the timestamp provided.  
> This behavior is not the one seen in bash and java as explained in the question.  
> I haven't found the bug here but I may be wrong, and it may be fixed already. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)