decoding types within the hbase shell

[Max Garfinkel <ma...@talk21.com>]

Hi All,
I think this is a stupid question but I cant seem to find an answer one way or 
the other anywhere else so here goes. Is it possible to decode the values stored 
in columns to something other than string when performing a scan using the hbase 
shell?

To be really clear I have a table containing three columns: duration, frequency 
and trailstring which are storing the bytes that make an int, long and string 
respectively. I am fine decoding them in my application but I would like to be 
able to see them represented as there types in the shell, instead of the garbage 
that is produced, presumably decoding there bytes into a string.

Is this possible? also I don't really know much about ruby.

Many thanks

max  

Re: decoding types within the hbase shell

[Ted Yu <yu...@gmail.com>]

Some code from Andrey:

## function converts any value to bytes (using Bytes class methods)
def toBytes(val)
    String.from_java_bytes(Bytes.
toBytes(val))
end

## example analog of the "select * from where key"
def fetch(table, id, args = {})
  key = Writables.getBytes(BsnId.new(id))
  print Bytes.toStringBinary(key); print "\n"
  get table, String.from_java_bytes(key), args
end


On Sun, Jan 16, 2011 at 4:39 AM, Max Garfinkel <ma...@talk21.com>wrote:

> Hi All,
> I think this is a stupid question but I cant seem to find an answer one way
> or
> the other anywhere else so here goes. Is it possible to decode the values
> stored
> in columns to something other than string when performing a scan using the
> hbase
> shell?
>
> To be really clear I have a table containing three columns: duration,
> frequency
> and trailstring which are storing the bytes that make an int, long and
> string
> respectively. I am fine decoding them in my application but I would like to
> be
> able to see them represented as there types in the shell, instead of the
> garbage
> that is produced, presumably decoding there bytes into a string.
>
> Is this possible? also I don't really know much about ruby.
>
> Many thanks
>
> max