hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Disable Base64 encoding in Stargate request and Return as String
Date Fri, 07 Aug 2015 00:28:41 GMT
Unfortunately we can't change the current set of representations are
returned from the shell, that would be a backwards compatibility problem.
We can however add new representations (selectable by way of the Accept
header, e.g. Accept: text/plain). If you'd like to propose a patch we'd
certainly look at it.

Thanks.


On Wed, Aug 5, 2015 at 12:51 AM, anil gupta <anilgupta84@gmail.com> wrote:

> Hi Andrew,
>
> Thanks for sharing your thoughts. Sorry for late reply as i recently came
> back from vacation.
> I understand that HBase stores byte arrays, so its hard for HBase to figure
> out the data type.
> What if, the client knows that all the columns in the Rest request are
> Strings. In that case, can we give the option of setting a request header
> "StringDecoding:True". By default, we can assume "StringDecoding: false".
> Just some food for thought.
>
> Also, if we can replicate the Encoding that we do in HBase Shell(where
> string are shown in readable format and we hex encode all binary data).
> That would be best. In this case, it would be really convenient use of Rest
> service rather than invoking "hbase shell". Right now, IMO, due to lack of
> readability its only good to fetch images.(we store images in HBase)
>
> Provided my employer allows me to contribute, I am willing to work on this.
> Would HBase accept a patch?
>
> Thanks,
> Anil Gupta
>
> On Fri, Jul 17, 2015 at 4:57 PM, Andrew Purtell <apurtell@apache.org>
> wrote:
>
> > ​
> > ​
> > The closest you can get to just a string is have your client use an
> accept
> > header of "Accept: application/octet-stream" with making a query. This
> will
> > return zero or one value in the response. If a value is present in the
> > table at the requested location, the response body will be the unencoded
> > bytes. If you've stored a string, you'll get back a string. If you've
> > stored an image, you'll get back the raw image bytes. Note that using an
> > accept header of "application/octet-stream" implicitly limits you to
> > queries that only return zero or one values. (Strictly speaking, per the
> > package doc: "If binary encoding is requested, only one cell can be
> > returned, the first to match the resource specification. The row, column,
> > and timestamp associated with the cell will be transmitted in X headers:
> > X-Row, X-Column, and X-Timestamp, respectively. Depending on the
> precision
> > of the resource specification, some of the X-headers may be elided as
> > redundant.")
> > ​
> > ​In general, the REST gateway supports
> >
> > ​several ​
> > alternate encodings. See
> >
> >
> https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/rest/package-summary.html
> > for some examples.
> >
> > Note that HBase
> > ​cell data
> >  is binary
> > ​, not string.
> > It
> > ​does not
> >  make sense to turn off base64 encoding for the default response
> encoding,
> > XML, because
> > ​that ​
> > would produce invalid XML
> > ​ if a value happens to include non XML safe bytes​
> > .
> > ​HBase can't know that in advance. We need to encode keys and values in a
> > safe manner to avoid blowing up your
> > client's XML.
> >
> > The same is roughly true for JSON.​
> >
> >
> > If your client sends an accept header of "Accept: application/protobuf"
> > you'll get back a protobuf encoded object. Your client will need to be
> > prepared to handle that representation. This is probably not what you
> want.
> >
> > Why are we
> > ​even ​
> > talking about using XML
> > ​, JSON,​
> > ​ or
> >  protobuf to
> > ​encode
> >  responses? Because for many types of REST queries, HBase
> > ​must return ​
> > a structured response.
> > ​The client has asked for more than
> > simply
> > ​one value, simply one string​
> > . The response
> > ​must include
> > key
> > ​s​
> > ,
> > ​values
> > ,
> > ​timestamps
> > ​;
> >  maybe a whole row
> > ​'s worth​
> > of
> > ​keys, values, and timestamps
> > ​;
> >  maybe multiple rows. It depends on the query you issued.
> > ​ (See the '​
> > Cell or Row Query (Multiple Values)
> > ​' section in the package doc.)​
> >
> >
> >
> >
> > On Fri, Jul 17, 2015 at 2:20 PM, anil gupta <anilgupta84@gmail.com>
> wrote:
> >
> > > Hi All,
> > >
> > > We have a String Rowkey. We have String values of cells.
> > > Still, Stargate returns the data with Base64 encoding due to which a
> user
> > > cant read the data. Is there a way to disable Base64 encoding and then
> > Rest
> > > request would just return Strings.
> > >
> > > --
> > > Thanks & Regards,
> > > Anil Gupta
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Thanks & Regards,
> Anil Gupta
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message