[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-18824:
-----------------------------
Description:
Thanks to [Jerry and Chia-Ping Tsai's
comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
to correct my wrong understanding.
The following documentation says that by default(when the timestamp is not
specified for Put or Delete), the system uses the server's
{{currentTimeMillis}}.
1. In chapter 27.2.4 Put
bq. Doing a put always creates a new version of a cell, at a certain timestamp.
{color:#205081}By default the system uses the server’s
currentTimeMillis{color}, ...
2. In chapter 27.2.5 Delete
bq. Deletes work by creating tombstone markers. For example, let’s suppose we
want to delete a row. For this you can specify a version, or else
{color:#205081}by default the currentTimeMillis is used.{color}...
It seems not consistent with the code. Because in the client side's code, when
timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which is
Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
However, the documentation is correct, because those timestamps will be
replaced with server's {{currentTimeMillis}}
was:
Thanks to [Jerry and Chia-Ping Tsai's
comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
to correct my wrong understanding.
The following documentation says that by default(when the timestamp is not
specified for Put or Delete), the system users the server's currentTimeMillis.
1. In chapter 27.2.4 Put
bq. Doing a put always creates a new version of a cell, at a certain timestamp.
{color:#205081}By default the system uses the server’s
currentTimeMillis{color}, ...
2. In chapter 27.2.5 Delete
bq. Deletes work by creating tombstone markers. For example, let’s suppose we
want to delete a row. For this you can specify a version, or else
{color:#205081}by default the currentTimeMillis is used.{color}...
It seems not consistent with the code. Because in the client side's code, when
timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which is
Long.MAX_VALUE, rather than currentTimeMillis. But actually the documentation
is correct, because the timestamp will be replaced with server's
currentTimeMillis
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
> ------------------------------------------------------------------------------------
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
> Reporter: Xiang Li
> Assignee: Xiang Li
> Priority: Minor
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), the system uses the server's
> {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because those timestamps will be
> replaced with server's {{currentTimeMillis}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
