hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Larsen" <clar...@euphoriaaudio.com>
Subject RE: Problem deleting neighboors with timestamp=0
Date Mon, 19 Nov 2012 21:25:03 GMT
Filed: HBASE-7189

-----Original Message-----
From: Chris Larsen [mailto:clarsen@euphoriaaudio.com] 
Sent: Monday, November 19, 2012 3:41 PM
To: user@hbase.apache.org
Subject: RE: Problem deleting neighboors with timestamp=0

> So you are going to file a bug saying why 0 timestamp entry was allowed?
or why the delete command deleted the row with 0 
> timestamp also when that row was not specified in the delete command?

For the delete command so that rows with a ts=0 are not marked for deletion
inadvertently. Thanks Ram.

-----Original Message-----
From: ramkrishna vasudevan [mailto:ramkrishna.s.vasudevan@gmail.com]
Sent: Monday, November 19, 2012 1:15 PM
To: user@hbase.apache.org
Subject: Re: Problem deleting neighboors with timestamp=0

Hi Chris
So you are going to file a bug saying why 0 timestamp entry was allowed? or
why the delete command deleted the row with 0 timestamp also when that row
was not specified in the delete command?

Regards
Ram

On Mon, Nov 19, 2012 at 9:54 PM, Chris Larsen
<clarsen@euphoriaaudio.com>wrote:

> > IMHO, onus of ensuring the right Timestamp value should always be on 
> > the
> application logic rather than HBase. Essentially,
> > timestamp is long number in HBase. So, Timestamp with value of '0' 
> > seems
> to be a valid value. What if someone really wants to use
> > the value 0 as timestamp? HBase is used by a variety of users in 
> > quite
> different use cases. So, i dont think it would be a good idea of
> > introducing this restriction.
>
> That'd be fine with me. I'll file a bug report then in Jira. Thanks!
>
> -----Original Message-----
> From: anil gupta [mailto:anilgupta84@gmail.com]
> Sent: Monday, November 19, 2012 2:45 AM
> To: user@hbase.apache.org
> Subject: Re: Problem deleting neighboors with timestamp=0
>
> Hi Chris,
>
> My two cents...
> IMHO, onus of ensuring the right Timestamp value should always be on 
> the application logic rather than HBase. Essentially, timestamp is 
> long number in HBase. So, Timestamp with value of '0' seems to be a 
> valid value. What if someone really wants to use the value 0 as 
> timestamp? HBase is used by a variety of users in quite different use 
> cases. So, i dont think it would be a good idea of introducing this 
> restriction.
>
> HTH,
> Anil
>
>
> On Sun, Nov 18, 2012 at 9:45 PM, Chris Larsen
> <clarsen@euphoriaaudio.com>wrote:
>
> > > So you mean that you have explicitly set the timestamp to 0 for 
> > > the
> > column
> > which you did not want to delete?
> >
> > Yes, my code was setting the timestamp explicitly to 0. I fixed that 
> > bug in my code (since I do want a valid timestamp) but I was 
> > wondering if a timestamp of 0 is "legal" and if it isn't, maybe 
> > HBase should kick back errors if someone tries it.
> >
> > -----Original Message-----
> > From: ramkrishna vasudevan [mailto:ramkrishna.s.vasudevan@gmail.com]
> > Sent: Sunday, November 18, 2012 11:31 PM
> > To: user@hbase.apache.org
> > Subject: Re: Problem deleting neighboors with timestamp=0
> >
> > Hi Chris
> >
> > So you mean that you have explicitly set the timestamp to 0 for the 
> > column which you did not want to delete?
> >
> > Regards
> > Ram
> >
> > On Mon, Nov 19, 2012 at 1:44 AM, Chris Larsen
> > <clarsen@euphoriaaudio.com>wrote:
> >
> > > Hello, I was going nuts over an issue where I would try to delete 
> > > a single column but a neighboring column (sorted by the column 
> > > names in
> > > bytes) was also being deleted because, I found out, the timestamp 
> > > for the neighbor was set to 0. Here are some of the columns in the 
> > > row (taken from the shell
> > > utility)
> > >
> > >
> > >
> > > hbase(main):002:0> get 'mytable',
> > > "\x00\x01\xAA\x50\x8E\xC4\x20\x00\x00\x01\x00\x00\xAC"
> > >
> > > COLUMN                                  CELL
> > >
> > > t:\x00\x17                             timestamp=1351533601998,
> > > value=\x00\x00\x00\x00O\xB2\xDC[
> > >
> > > t:\x00\x17\x03\xD7\x...(long name)     timestamp=0,
value=\x00\x00\x...
> > > lots
> > > of binary data....
> > >
> > > t:\x03\xD7                             timestamp=1351533661458,
> > > value=\x00\x00\x00\x00O\xB9\xD1\xE5
> > >
> > > t:\x07\x97                             timestamp=1351533721758,
> > > value=\x00\x00\x00\x00O\xBC#\xD0
> > >
> > > t:\x0BW                                timestamp=1351533781738,
> > > value=\x00\x00\x00\x00O\xBD\xB93
> > >
> > >
> > >
> > > I wanted to delete the column "t:\x00\x17" but every time I did, 
> > > the column "t:\x00\x17\x03\xD7\x..." would also be deleted so that 
> > > I'd wind
> > up
> > with:
> > >
> > >
> > >
> > > hbase(main):005:0> get 'mytable',
> > > "\x00\x01\xAA\x50\x8E\xC4\x20\x00\x00\x01\x00\x00\xAC"
> > >
> > > COLUMN                                  CELL
> > >
> > > t:\x03\xD7                             timestamp=1351533661458,
> > > value=\x00\x00\x00\x00O\xB9\xD1\xE5
> > >
> > > t:\x07\x97                             timestamp=1351533721758,
> > > value=\x00\x00\x00\x00O\xBC#\xD0
> > >
> > > t:\x0BW                                timestamp=1351533781738,
> > > value=\x00\x00\x00\x00O\xBD\xB93
> > >
> > >
> > >
> > > My JAVA code looked like this:
> > >
> > >
> > >
> > > HTableInterface table = factory.createHTableInterface(config,
> > > "mytable".getBytes());
> > >
> > > Delete delete = new
> > > Delete(HexToBytes("0001AA508EC4200000010000AC"));
> > >
> > > delete.deleteColumn("t".getBytes(), new byte[] { (byte) 0x00,
> > > (byte)
> > > 0x17 });
> > >
> > > table.delete(delete);
> > >
> > >
> > >
> > > as I was typing this out, I noticed that the column I didn't want 
> > > to delete had a timestamp of 0. I put the column back with a valid 
> > > timestamp and tried deleting the original column, and it worked 
> > > properly. I fixed my code to always provide a positive timestamp, 
> > > but my question is, are timestamps set to 0 valid for storing data 
> > > in HBase? And if so, then this may be a bug that needs addressing.
> > > Thanks!
> > >
> > >
> >
> >
>
>
> --
> Thanks & Regards,
> Anil Gupta
>
>



Mime
View raw message