[jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)

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