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

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


+
Nick Dimiduk 2013-02-21, 18:35
+
Jonathan Hsieh 2013-02-21, 23:04
+
lars hofhansl 2013-02-22, 04:24
+
Enis Söztutar 2013-02-22, 03:23
+
Jonathan Hsieh 2013-02-22, 07:56
+
Nick Dimiduk 2013-02-22, 14:13
+
Jonathan Hsieh 2013-02-22, 14:31
+
Elliott Clark 2013-02-22, 17:32
Copy link to this message
-
Re: Review request for HBASE-7692: Ordered byte[] serialization
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 jira
> it
> > > is
> > > > > not
> > > > > > clear to my why this is inside hbase as part of hbase-common.
> > > > > >
> > > > > > Why isn't this part of a library on top of hbase (a dependency
> for
> > > > > > Pig/Hive) instead of "inside" hbase?
> > > > > > Can't this functionality be done just from the client level?
> > > > > > What's the end goal hee? Is the goal here to replace the
+
Nick Dimiduk 2013-02-22, 18:04
+
Matt Corgan 2013-02-22, 18:14
+
Nick Dimiduk 2013-02-22, 18:48
+
Nick Dimiduk 2013-02-22, 19:37
+
Ted Yu 2013-02-22, 21:14
+
Stack 2013-02-26, 23:13
+
Jesse Yates 2013-02-22, 18:01
+
Nick Dimiduk 2013-02-22, 23:13
+
Jonathan Hsieh 2013-02-23, 00:33
+
Matt Corgan 2013-02-23, 00:48
+
Nick Dimiduk 2013-02-23, 01:40
+
Matt Corgan 2013-02-23, 02:04
+
Stack 2013-02-26, 23:20
+
Stack 2013-02-26, 23:17
+
Ted 2013-02-22, 14:21
+
Stack 2013-02-26, 23:08