hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Latham (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-1930) Put.setTimeStamp misleading (doesn't change timestamp on existing KeyValues, not copied in copy constructor)
Date Fri, 23 Oct 2009 15:54:59 GMT

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


Mime
View raw message