Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Review request for HBASE-7692: Ordered byte[] serialization


Copy link to this message
-
Re: Review request for HBASE-7692: Ordered byte[] serialization
+1 on all Matt's comments
-------------------
Jesse Yates
@jesse_yates
jyates.github.com
On Fri, Feb 22, 2013 at 10:00 AM, Matt Corgan <[EMAIL PROTECTED]> wrote:

> To nitpick a little it wouldn't quite be a sibling of hbase-client because
> hbase-client depends on hbase-common and hbase-protocol while this new one
> will not depend on anything.  Would hbase-server be able to see it?  Would
> it basically be a standalone module being maintained by HBase?
>
> Also, assuming the original Orderly library goes unmaintained and we want
> people to use it, this will be the primary place to get it.  Having no
> dependencies on other hbase modules is important for people who want to use
> the Orderly library for something unrelated to hbase.  For example, a web
> application that logs data in this format but not directly to hbase.
>
>
> On Fri, Feb 22, 2013 at 9:32 AM, Elliott Clark <[EMAIL PROTECTED]> wrote:
>
> > Yep the client will be fully separated as soon as rpc changes
> > are stabilized.  Until then keeping up the move patch was just too
> onerous.
> >
> >
> > On Fri, Feb 22, 2013 at 6:31 AM, Jonathan Hsieh <[EMAIL PROTECTED]>
> wrote:
> >
> > > Nick,
> > >
> > > I'm +1 for it having its own module, and being a sibling of
> hbase-client.
> > >  I'm assuming the client stuff will happen before we release 0.96 since
> > it
> > > has been started.
> > >
> > > Jon.
> > >
> > > On Fri, Feb 22, 2013 at 6:13 AM, Nick Dimiduk <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > You're absolutely correct: this library introduces client-side
> > > conventions
> > > > and is not needed from within the HMaster or RegionServer. Is
> > > > the consensus that it should reside in it's own module or be a
> sibling
> > to
> > > > the o.a.h.hbase.client source tree? I'm a little confused by the
> > current
> > > > state of the modules; hbase-client looks empty while
> o.a.h.hbase.client
> > > > sits under hbase-server.
> > > >
> > > > Thanks,
> > > > Nick
> > > >
> > > > On Thu, Feb 21, 2013 at 11:56 PM, Jonathan Hsieh <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > > So I buy the argument about this being included in hbase, but
> several
> > > of
> > > > > the questions still stand --
> > > > >
> > > > > Why is this part of hbase-common?  shouldn't this be just a
> > dependency
> > > of
> > > > > hbase-client module?  Does the hbase-server side need to depend on
> > > this?
> > > > >
> > > > > Since this is a large import of a currently isolated library, why
> not
> > > > make
> > > > > it a separate module instead of part of hbase-common?  This would
> > > > enforce a
> > > > > boundary that will prevent pollution from circular dependencies.
> > > > >
> > > > > Jon.
> > > > >
> > > > > On Thu, Feb 21, 2013 at 7:23 PM, Enis Söztutar <[EMAIL PROTECTED]>
> > > wrote:
> > > > >
> > > > > > I think this belongs in core HBase, as a replacement to Bytes,
> > which
> > > > > should
> > > > > > be deprecated eventually. We have a Bytes utility which is
> supposed
> > > to
> > > > > > convert basic java types to byte[]'s, but it does not work for
> > signed
> > > > > > numbers.
> > > > > >
> > > > > > We already know that all of the clients, Hive, Pig, Phoenix, have
> > to
> > > > have
> > > > > > at least java type -> byte[] conversion utilities, and I think it
> > is
> > > > > > HBase's job to supply one so that different clients can
> > interoperate.
> > > > > Since
> > > > > > internally we are also relying on serializing java types, we need
> > > that
> > > > > > library in the core.
> > > > > >
> > > > > > BTW, I also think that we need to have a SQL-type to java type to
> > > > byte[]
> > > > > > layer, but that is another discussion.
> > > > > >
> > > > > > Enis
> > > > > >
> > > > > >
> > > > > > On Thu, Feb 21, 2013 at 3:04 PM, Jonathan Hsieh <
> [EMAIL PROTECTED]>
> > > > > wrote:
> > > > > >
> > > > > > > Nick,
> > > > > > >
> > > > > > > While I believe having an order-preserving canonical
> > serialization
> > > > is a
> > > > > > > good idea,  from doing a read of the mail and a skim of the