Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <482548244.1256248439395.JavaMail.jira@brutus>
Date: Thu, 22 Oct 2009 21:53:59 +0000 (UTC)
From: "Jonathan Gray (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-1930) Put.setTimeStamp misleading (doesn't
 change timestamp on existing KeyValues, not copied in copy constructor)
In-Reply-To: <1750581611.1256244059540.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.