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
Nick Dimiduk 2013-02-22, 18:48
On Fri, Feb 22, 2013 at 10:14 AM, Matt Corgan <[EMAIL PROTECTED]> wrote:

> >
> > Not quite true. It makes use of Bytes and ImmutableBytesWritable from
> > hbase-common.
>
> Oh, interesting.  Could we inline the code from Bytes.java and somehow get
> rid of the ImmutableBytesWritable.  Like calling packages can add
> ImmutableBytesWritable functionality on top if they want to?
I'll need to do a more thorough evaluation, but a cursory glance indicates
use of Bytes could be replaced by arraycopy. ImmutableBytesWritable is used
mostly as a convenient wrapper over byte[], and may well
be replaceable with Hadoop's BytesWritable.

Seems like something as low level as rearranging bytes should be dependency
> free.
>

The implementation makes heavy use of Hadoop Writables, but the
dependencies on HBase instances are mostly convenience.

 On Fri, Feb 22, 2013 at 10:04 AM, Nick Dimiduk <[EMAIL PROTECTED]> wrote:
>
> > Inline.
> >
> > 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?
> > >
> >
> > Not quite true. It makes use of Bytes and ImmutableBytesWritable from
> > hbase-common.
> >
> > 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.
> > >
> >
> > Orderly has gone unmaintained. The only fork with any activity that I'm
> > aware of is my own. I'd much rather see it gain the publicity,
> > additional scrutiny, wider adoption than continue as a pet-project.
> >
> > 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