[jira] [Commented] (HBASE-18824) Default timestamp for Put and Delete is not System.currentTimeMillis(), but Long.MAX_VALUE

2017-09-17 Thread Xiang Li (JIRA)

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

Xiang Li commented on HBASE-18824:
--

Got you, [~jerryhe], [~chia7712]! I will do it. 

> Default timestamp for Put and Delete is not System.currentTimeMillis(), but 
> Long.MAX_VALUE
> --
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
>
> In http://hbase.apache.org/book.html#versions,
> 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}...
> Checking the code, when timestamp is not specified, 
> HConstants.LATEST_TIMESTAMP is used, which is Long.MAX_VALUE, rather than 
> System.currentTimeMillis()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (HBASE-18824) Default timestamp for Put and Delete is not System.currentTimeMillis(), but Long.MAX_VALUE

2017-09-16 Thread Chia-Ping Tsai (JIRA)

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

Chia-Ping Tsai commented on HBASE-18824:


Nice suggestion.  [~water] What do yo think?

> Default timestamp for Put and Delete is not System.currentTimeMillis(), but 
> Long.MAX_VALUE
> --
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
>
> In http://hbase.apache.org/book.html#versions,
> 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}...
> Checking the code, when timestamp is not specified, 
> HConstants.LATEST_TIMESTAMP is used, which is Long.MAX_VALUE, rather than 
> System.currentTimeMillis()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (HBASE-18824) Default timestamp for Put and Delete is not System.currentTimeMillis(), but Long.MAX_VALUE

2017-09-15 Thread Jerry He (JIRA)

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

Jerry He commented on HBASE-18824:
--

One thing that can be improved is to add meaningful comment for the field 
HConstants.LATEST_TIMESTAMP to make it more clear for people who are into 'how 
it works'.

> Default timestamp for Put and Delete is not System.currentTimeMillis(), but 
> Long.MAX_VALUE
> --
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
>
> In http://hbase.apache.org/book.html#versions,
> 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}...
> Checking the code, when timestamp is not specified, 
> HConstants.LATEST_TIMESTAMP is used, which is Long.MAX_VALUE, rather than 
> System.currentTimeMillis()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (HBASE-18824) Default timestamp for Put and Delete is not System.currentTimeMillis(), but Long.MAX_VALUE

2017-09-15 Thread Hadoop QA (JIRA)

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

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 
18s{color} | {color:blue} Docker mode activated. {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 
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  1m 
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  9m 
32s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  2m 
 0s{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 
21s{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 47s{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} javadoc {color} | {color:green}  2m 
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}144m 
44s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
20s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}205m 51s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18824 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12887258/HBASE-18824.master.000.patch
 |
| Optional Tests |  asflicense  shadedjars  javac  javadoc  unit  |
| uname | Linux 251ebe2808f1 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 / 5c07dba |
| Default Java | 1.8.0_144 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8639/testReport/ |
| modules | C: . U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8639/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> Default timestamp for Put and Delete is not System.currentTimeMillis(), but 
> Long.MAX_VALUE
> --
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
>
> In http://hbase.apache.org/book.html#versions,
> 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}...
> Checking the code, when timestamp is not specified, 
> HConstants.LATEST_TIMESTAMP is used, which is Long.MAX_VALUE, rather than 
> System.currentTimeMillis()



--

[jira] [Commented] (HBASE-18824) Default timestamp for Put and Delete is not System.currentTimeMillis(), but Long.MAX_VALUE

2017-09-15 Thread Chia-Ping Tsai (JIRA)

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

Chia-Ping Tsai commented on HBASE-18824:


The HConstants.LATEST_TIMESTAMP(Long.MAX_VALUE) is a *notation*. Any PUT cell 
having the *notation* will be replaced it's timestamp with server's 
{{currentTimeMillis}}. If you change the description from {{currentTimeMillis}} 
to {{Long.MAX_VALUE}}, that may confuse user because the timestamp of cell we 
store is server's {{currentTimeMillis}}.

> Default timestamp for Put and Delete is not System.currentTimeMillis(), but 
> Long.MAX_VALUE
> --
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch
>
>
> In http://hbase.apache.org/book.html#versions,
> 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}...
> Checking the code, when timestamp is not specified, 
> HConstants.LATEST_TIMESTAMP is used, which is Long.MAX_VALUE, rather than 
> System.currentTimeMillis()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (HBASE-18824) Default timestamp for Put and Delete is not System.currentTimeMillis(), but Long.MAX_VALUE

2017-09-14 Thread Xiang Li (JIRA)

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

Xiang Li commented on HBASE-18824:
--

yes, [~jerryhe], I plan to make this small change on doc.

> Default timestamp for Put and Delete is not System.currentTimeMillis(), but 
> Long.MAX_VALUE
> --
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
>
> In http://hbase.apache.org/book.html#versions,
> 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}...
> Checking the code, when timestamp is not specified, 
> HConstants.LATEST_TIMESTAMP is used, which is Long.MAX_VALUE, rather than 
> System.currentTimeMillis()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (HBASE-18824) Default timestamp for Put and Delete is not System.currentTimeMillis(), but Long.MAX_VALUE

2017-09-14 Thread Jerry He (JIRA)

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

Jerry He commented on HBASE-18824:
--

Hi, [~water]  The real default timestamp is applied on the server side when the 
server sees Integer.MAX_VALUE, if this is what you mean.

> Default timestamp for Put and Delete is not System.currentTimeMillis(), but 
> Long.MAX_VALUE
> --
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
>
> In http://hbase.apache.org/book.html#versions,
> 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}...
> Checking the code, when timestamp is not specified, 
> HConstants.LATEST_TIMESTAMP is used, which is 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)