[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

Thanks very much [~jerryhe] for the suggestion!

> 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
> Fix For: 2.0.0
>
> Attachments: HBASE-18824.master.000.patch, 
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch, 
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

Thanks very much [~chia7712] for the suggestion and patience!

> 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
> Fix For: 2.0.0
>
> Attachments: HBASE-18824.master.000.patch, 
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch, 
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Hudson (JIRA)]

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

Hudson commented on HBASE-18824:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3927 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/3927/])
HBASE-18824 Add meaningful comment to HConstants.LATEST_TIMESTAMP to (chia7712: 
rev 2ee8690b47763fd0ed97d47713b1c516633f597b)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java


> 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
> Fix For: 2.0.0
>
> Attachments: HBASE-18824.master.000.patch, 
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch, 
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


Will commit it later

> 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, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch, 
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18824:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 19m 
55s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
37s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  0m 
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  3m 
59s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
36m 38s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  0m 
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m  
1s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
 8s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 74m 46s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-18824 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12893425/HBASE-18824.master.005.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 8c4cf9e40fbc 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31 
14:13:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / 592d541 |
| Default Java | 1.8.0_141 |
| findbugs | v3.1.0-RC3 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9308/testReport/ |
| modules | C: hbase-common U: hbase-common |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9308/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


LGTM, Nice comment!

> 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, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch, 
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

Hi [~chia7712], thanks for your comment and patience!

1. Regarding
bq. The exeption is caused by that the number of cells we get is greater than 
the max version we set to Get. That is unrelated to the Delete cells.
Yes, it is. But the max version we set to Get is the count of Delete cell, 
which is recorded in a TreeMap called kvCount, mapping from qualifier to the 
count of cell of that qualifier.

2. Regarding
bq. The count of cells we get for the Delete may be not equal with the count of 
existing cells. The comment may mislead us about the data model of HBase. For 
example, 4 Put cells exist in server, and then a Delete having 3 Delete cells 
is submitted to server. The count of existing cells is 4, so the Delete 
operation will fail?
Yes, it is not accurate to use the statement of "existing cell". 

Patch 004 is uploaded to remove the usage of "existing cell". Thanks for the 
suggestions!

> 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, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


{quote}
+   *c. When the count of existing cells is greater than the count to 
delete,
+   *   it is an invalid condition, as the max version to get is set to 
the count to delete.
{quote}
The count of cells we get for the {{Delete}} may be not equal with the count of 
existing cells. The comment may mislead us about the data model of HBase. For 
example, 4 Put cells exist in server, and then a {{Delete}} having 3 Delete 
cells is submitted to server. The *count of existing cells* is 4, so the Delete 
operation will fail?  

> 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, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


The exeption is caused by that the number of cells we get is greater than the 
max version we set to Get. That is unrelated the Delete cells. 

> 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, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18824:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} docker {color} | {color:red}  2m 
50s{color} | {color:red} Docker failed to build yetus/hbase:4a7b430. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18824 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12893049/HBASE-18824.master.004.patch
 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9216/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> 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, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

Uploaded patch 004, by adding the explanation for the condition when 
result.size() > count.

> 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, 
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

[~chia7712], thanks for your time for the review!
Regarding
bq. equal to -> greater than or equal to
I might get your idea to make the comment to cover all conditions (>, < and =), 
so as to avoid confusion. But the condition of result.size() > count, that is 
"great than", is invalid. I might prefer the current comment (only talking 
about the conditions of less than and equal). How do you feel about it?

> 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, 
> HBASE-18824.master.003.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


bq. When the count of existing cells is equal to the count to delete,
equal to -> greater than or equal to

> 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, 
> HBASE-18824.master.003.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


+1

> 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, 
> HBASE-18824.master.003.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


Will commit it later.

> 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, 
> HBASE-18824.master.003.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


What I mean is v2 patch need to be updated. greater -> less

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

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

[~chia7712], any comment to patch 002? 8-)

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

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

Yes, I believe the reason why {{result.size() > count}} is an exception which 
should not happen is the max version of Get is set to count 
{code:title=HRegion.java|borderStyle=solid}
public void prepareDeleteTimestamps(Mutation mutation, Map 
familyMap,
  byte[] byteNow) throws IOException {
  //...
  Get get = new Get(CellUtil.cloneRow(cell));
  get.setMaxVersions(count); <-- here
  get.addColumn(family, qual);
  if (coprocessorHost != null) {
if (!coprocessorHost.prePrepareTimeStampForDeleteVersion(mutation, 
cell,
byteNow, get)) {
  updateDeleteLatestVersionTimeStamp(cell, get, count, byteNow);
}
  } else {
updateDeleteLatestVersionTimeStamp(cell, get, count, byteNow);
  }
}
{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=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


bq. 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 8-)
Yep. BTW, the {{result.size() > count}} is a exception which should not happen.

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

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

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

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18824:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
12s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
25s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  0m 
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  0m 
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
 9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
 1s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
39m 53s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  0m 
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
23s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
 8s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 54m 29s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18824 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12892287/HBASE-18824.master.002.patch
 |
| Optional Tests |  asflicense  shadedjars  javac  javadoc  unit  findbugs  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux f8374e521503 3.13.0-119-generic #166-Ubuntu SMP Wed May 3 
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / 202e414 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9126/testReport/ |
| modules | C: hbase-common U: hbase-common |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9126/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


{quote}
When the size of Get's result is greater than count (to be deleted), the code 
updates the timestamp to server's current time
When the size of Get's result is equal to count(to be deleted), the code 
updates the timestamp to the latest version of what could be Get (why?)
{quote}
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.

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

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

[~chia7712], would you please review patch 002 at your most convenience?

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

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


bq.  the code updates the timestamp to the latest version of what could be Get 
(why?)
To delete the latest cell, the cell having delete mark should be set the 
timestamp of latest cell.

bq. Do I get it correctly?
Yep, please update the patch. Thanks.

> 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
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

[~chia7712], thanks for guide! 
I read the code of {{HRegion#updateDeleteLatestVersionTimeStamp()}} as well as 
{{HRegion#prepareDeleteTimestamps()}}, and step 2 of 
{{HRegion#doMiniBatchMutate()}}.

The code calls prepareDeleteTimestamps() if the mutation is not Put(Could be 
Delete, but could it be Increment or Append?). Loop for each cell list of 
column family, and loop for each cell.

It operates differently in 2 conditions, one is for Type.Delete, the other is 
for Type.DeleteFamily, Type.DeleteFamilyVersion or Type.DeleteColumn. 
* For Type.Delete
** When the size of Get's result is greater than count (to be deleted), the 
code updates the timestamp to server's current time
** When the size of Get's result is equal to count(to be deleted), the code 
updates the timestamp to the latest version of what could be Get (why?)
* For other types (Type.DeleteFamily, Type.DeleteFamilyVersion or 
Type.DeleteColumn), update the timestamp to server's current time when it is 
LATEST_TIMESTAMP. 

Do I get it correctly?

> 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
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


bq. the logic is the same: update the ts with LATEST_TIMESTAMP to current on 
server's side.
Not really. There are various Delete operation, namely Delete, DeleteFamily, 
DeleteFamilyVersion, and DeleteColumn, so you need to check how they use the 
{{HConstants.LATEST_TIMESTAMP}}. Please take a look at 
{{HRegion#updateDeleteLatestVersionTimeStamp}}. 

> 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
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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 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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

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

Xiang Li commented on HBASE-18824:
--

[~chia7712], thanks for the review. It is addressed by patch 001.
If I read the code correctly, for a cell of Put or Delete, the logic is the 
same: update the ts with LATEST_TIMESTAMP to current on server's side. Please 
correct me if I am wrong.

> 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
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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 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)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18824:


Nice work. BTW, Could you also add comment about how Delete uses the 
HConstants.LATEST_TIMESTAMP?

> 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
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=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 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)