You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Dave Latham (JIRA)" <ji...@apache.org> on 2009/10/22 22:40:59 UTC
[jira] Created: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
------------------------------------------------------------------------------------------------------------
Key: HBASE-1930
URL: https://issues.apache.org/jira/browse/HBASE-1930
Project: Hadoop HBase
Issue Type: Bug
Components: client
Affects Versions: 0.20.1, 0.20.0
Reporter: Dave Latham
Priority: Minor
Fix For: 0.20.2
Attachments: 1930.patch
In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768994#action_12768994 ]
stack commented on HBASE-1930:
------------------------------
Should the below be passing on the rowlock? It doesn't seem to be? (Might be just my reading of patch in isolation)
{code}
Index: src/java/org/apache/hadoop/hbase/client/Put.java
===================================================================
--- src/java/org/apache/hadoop/hbase/client/Put.java (revision 828839)
+++ src/java/org/apache/hadoop/hbase/client/Put.java (working copy)
@@ -75,6 +75,16 @@
* @param rowLock previously acquired row lock, or null
*/
public Put(byte [] row, RowLock rowLock) {
+ this(row, HConstants.LATEST_TIMESTAMP, null);
+ }
{code}
Otherwise +1
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.0, 0.20.1
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 1930.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "Dave Latham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Latham updated HBASE-1930:
-------------------------------
Attachment: (was: 1930.patch)
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.0, 0.20.1
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 1930-trunk.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "Jonathan Gray (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768927#action_12768927 ]
Jonathan Gray commented on HBASE-1930:
--------------------------------------
Good catch.
Patch looks good, Dave. Will run it through tests tomorrow and commit if no one else does before me. Thanks.
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.0, 0.20.1
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 1930.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "Dave Latham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Latham updated HBASE-1930:
-------------------------------
Attachment: 1930.patch
proposed patch removes setTimestamp, adds timestamp as a constructor arg, modifies copy constructor to copy timestamp and writeToWAL
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.0, 0.20.1
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.20.2
>
> Attachments: 1930.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "Dave Latham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Latham updated HBASE-1930:
-------------------------------
Attachment: 1930-trunk.patch
Updated the patch to match trunk, fix up some javadoc and tests. All tests pass locally.
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.0, 0.20.1
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 1930-2.patch, 1930-trunk.patch, 1930.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "Dave Latham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Latham updated HBASE-1930:
-------------------------------
Status: Patch Available (was: Open)
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.1, 0.20.0
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 1930-trunk.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HBASE-1930:
-------------------------
Resolution: Fixed
Hadoop Flags: [Reviewed]
Status: Resolved (was: Patch Available)
Thanks for the patch Dave.
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.0, 0.20.1
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 1930-trunk.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "Dave Latham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Latham updated HBASE-1930:
-------------------------------
Attachment: (was: 1930-2.patch)
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.0, 0.20.1
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 1930-trunk.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "Dave Latham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Latham updated HBASE-1930:
-------------------------------
Attachment: 1930-2.patch
You're absolutely right, Stack. That's what I get to revising the constructors too many times. Here's a revised patch.
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.0, 0.20.1
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 1930-2.patch, 1930.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't
change timestamp on existing KeyValues, not copied in copy constructor)
Posted by "Dave Latham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Latham updated HBASE-1930:
-------------------------------
Fix Version/s: (was: 0.20.2)
0.21.0
Realized this fix shouldn't go on branch, because it's an api change.
> Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-1930
> URL: https://issues.apache.org/jira/browse/HBASE-1930
> Project: Hadoop HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.0, 0.20.1
> Reporter: Dave Latham
> Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 1930.patch
>
>
> In the process of migrating some code from 0.19, and was changing BatchUpdate's to Put's. I was hit by a bit of a gotcha. In the old code, I populated the BatchUpdate, then set the timestamp. However, this doesn't wotk for Put, because Put creates KeyValue's with the currently set timestamp when adding values. Setting the timestamp at the end has no effect. Also, the copy constructor doesn't copy the timestamp (or writeToWAL) setting.
> One option would be to simply update the javadoc to make it clear that the timestamp needs to be set prior to adding values. I'm attaching a proposed patch which moves the timestamp setting to constructor only so that it isn't possible to trigger the confusing case at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.