A "...separate patch that doesn't introduce incompatibility .." for 0.20 branch sounds like a good idea. St.Ack
On Thu, Oct 29, 2009 at 11:11 AM, Dave Latham (JIRA) <[email protected]>wrote: > > [ > https://issues.apache.org/jira/browse/HBASE-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771528#action_12771528] > > Dave Latham commented on HBASE-1941: > ------------------------------------ > > See https://issues.apache.org/jira/browse/HBASE-1930 for some related > discussion. > > It doesn't actually affect TableOutputFormat because the timestamp in Put > only affects values added after it is set, and TableOutputFormat does not > add any values to the Put object. > > HBASE-1930 fixed this for trunk, but perhaps a separate patch that doesn't > introduce incompatibility would be good for the 0.20 branch. > > > Put's copy feature has a bug. > > ----------------------------- > > > > Key: HBASE-1941 > > URL: https://issues.apache.org/jira/browse/HBASE-1941 > > Project: Hadoop HBase > > Issue Type: Bug > > Components: client > > Affects Versions: 0.20.1 > > Reporter: Hyunsik Choi > > > > Put's copy feature has a bug. The copy does not consider the timestamp > value. > > In the following example, a put and its copied put prints out different > timestamps. > > {quote} > > Put put = new Put("abc".getBytes()); > > put.setTimeStamp(1); > > System.out.println(put.getTimeStamp()); > > Put put2 = new Put(put); > > System.out.println(put2.getTimeStamp()); > > --------------------------- > > Above source code results in as follows: > > 1 > > 9223372036854775807 > > {quote} > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
