[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207715#comment-16207715
]
Xiang Li edited comment on HBASE-18824 at 10/17/17 2:35 PM:
------------------------------------------------------------
Hi [~chia7712],
regarding
bq. Region try to find enough PUT cells to update the DELETE cells having the
LATEST_TIMESTAMP. If the number of PUT cells is greater than number of DELETE
cells, it means each DELETE cells have "latest" timestamp provided by real PUT
cell rather than server's ts. Pardon. I didn't check the comment entirely.
Are you talking about the following code in
HRegion#updateDeleteLatestVersionTimeStamp()? "the umber of PUT cells" you
mentioned is result.size() in the following code? Sorry, I am just trying to
fully understand your comment ^_^
{code}
void updateDeleteLatestVersionTimeStamp(Cell cell, Get get, int count, byte[]
byteNow)
throws IOException {
List<Cell> result = get(get, false);
if (result.size() < count) {
// Nothing to delete
CellUtil.updateLatestStamp(cell, byteNow, 0);
return;
}
if (result.size() > count) {
throw new RuntimeException("Unexpected size: " + result.size());
}
Cell getCell = result.get(count - 1);
CellUtil.setTimestamp(cell, getCell.getTimestamp());
}
{code}
was (Author: water):
Hi [~chia7712],
regarding
bq. Region try to find enough PUT cells to update the DELETE cells having the
LATEST_TIMESTAMP. If the number of PUT cells is greater than number of DELETE
cells, it means each DELETE cells have "latest" timestamp provided by real PUT
cell rather than server's ts. Pardon. I didn't check the comment entirely.
Are you talking about the following code in
HRegion#updateDeleteLatestVersionTimeStamp()? "the umber of PUT cells" you
mentioned is result.size() in the following code? Sorry, I just would like to
fully understand your comment ^_^
{code}
void updateDeleteLatestVersionTimeStamp(Cell cell, Get get, int count, byte[]
byteNow)
throws IOException {
List<Cell> result = get(get, false);
if (result.size() < count) {
// Nothing to delete
CellUtil.updateLatestStamp(cell, byteNow, 0);
return;
}
if (result.size() > count) {
throw new RuntimeException("Unexpected size: " + result.size());
}
Cell getCell = result.get(count - 1);
CellUtil.setTimestamp(cell, getCell.getTimestamp());
}
{code}
> 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
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch
>
>
> 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), 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 on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
