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