You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Dave Wang <ds...@cloudera.com> on 2012/01/21 01:31:20 UTC
hbase shell output question
Hello,
>From the hbase shell, I see this:
hbase(main):049:0> scan 't1'
ROW COLUMN+CELL
r1 column=f1:c1, timestamp=1327104295560, value=value
r1 column=f1:c2, timestamp=1327104330625, value=value
1 row(s) in 0.0300 seconds
hbase(main):050:0> deleteall 't1', 'r1'
0 row(s) in 0.0080 seconds <====== I expected this to read
"2 row(s)"
hbase(main):051:0> scan 't1'
ROW COLUMN+CELL
0 row(s) in 0.0090 seconds
Similar behavior for delete.
Is this a bug or am I misunderstanding what the output is supposed to mean?
If this is a bug, I can file a JIRA.
Regards,
- Dave
Re: hbase shell output question
Posted by Dave Wang <ds...@cloudera.com>.
I created HBASE-5251 <https://issues.apache.org/jira/browse/HBASE-5251> for
this.
- Dave
On Sun, Jan 22, 2012 at 9:21 AM, Lars George <la...@gmail.com> wrote:
> +1 on fixing this, I noticed this many times, but ignored it since I
> gotten used to it.
>
> On Jan 21, 2012, at 5:54 PM, Stack wrote:
>
> > On Fri, Jan 20, 2012 at 10:21 PM, Dave Wang <ds...@cloudera.com> wrote:
> >
> >> Looking at the ruby shell code, it seems that formatter.footer() is
> called
> >> even for commands that will not actually increment the number of rows
> >> reported, such as deletes. Perhaps there should be another similar
> >> function to formatter.footer(), but that will not print out @row_count.
> >>
> >>
> > Agreed. Mind filing an issue?
> > Thanks,
> > St.Ack
>
>
Re: hbase shell output question
Posted by Lars George <la...@gmail.com>.
+1 on fixing this, I noticed this many times, but ignored it since I gotten used to it.
On Jan 21, 2012, at 5:54 PM, Stack wrote:
> On Fri, Jan 20, 2012 at 10:21 PM, Dave Wang <ds...@cloudera.com> wrote:
>
>> Looking at the ruby shell code, it seems that formatter.footer() is called
>> even for commands that will not actually increment the number of rows
>> reported, such as deletes. Perhaps there should be another similar
>> function to formatter.footer(), but that will not print out @row_count.
>>
>>
> Agreed. Mind filing an issue?
> Thanks,
> St.Ack
Re: hbase shell output question
Posted by Stack <st...@duboce.net>.
On Fri, Jan 20, 2012 at 10:21 PM, Dave Wang <ds...@cloudera.com> wrote:
> Looking at the ruby shell code, it seems that formatter.footer() is called
> even for commands that will not actually increment the number of rows
> reported, such as deletes. Perhaps there should be another similar
> function to formatter.footer(), but that will not print out @row_count.
>
>
Agreed. Mind filing an issue?
Thanks,
St.Ack
Re: hbase shell output question
Posted by Dave Wang <ds...@cloudera.com>.
>
>
> The bug is that the status we output is 0 rows rather than two rows? (Or
> do you mean 1 row since only one row was deleted)?
>
You are right; I meant 1 row. As an end-user, I expected that I should see
that 1 row was deleted, instead of 0 rows. Or do not print out a number of
rows at all.
Looking at the ruby shell code, it seems that formatter.footer() is called
even for commands that will not actually increment the number of rows
reported, such as deletes. Perhaps there should be another similar
function to formatter.footer(), but that will not print out @row_count.
- Dave
Re: hbase shell output question
Posted by Stack <st...@duboce.net>.
On Fri, Jan 20, 2012 at 4:31 PM, Dave Wang <ds...@cloudera.com> wrote:
> Hello,
>
> From the hbase shell, I see this:
>
> hbase(main):049:0> scan 't1'
> ROW COLUMN+CELL
>
> r1 column=f1:c1, timestamp=1327104295560, value=value
>
> r1 column=f1:c2, timestamp=1327104330625, value=value
>
> 1 row(s) in 0.0300 seconds
>
> hbase(main):050:0> deleteall 't1', 'r1'
> 0 row(s) in 0.0080 seconds <====== I expected this to read
> "2 row(s)"
>
> hbase(main):051:0> scan 't1'
> ROW COLUMN+CELL
>
> 0 row(s) in 0.0090 seconds
>
> Similar behavior for delete.
>
> Is this a bug or am I misunderstanding what the output is supposed to mean?
> If this is a bug, I can file a JIRA.
>
>
The bug is that the status we output is 0 rows rather than two rows? (Or
do you mean 1 row since only one row was deleted)?
St.Ack