Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of ndimiduk@gmail.com designates
 209.85.212.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAG_TOPC2ZqkA5YA_Q4GwUNd5YDRgufPew7Kh-OLShSSOhfZnyg@mail.gmail.com>
References: 
 <CADcMMgG-0Me1fiz2=9sA=tmeUp0jVmDY5O1koPqcPeoh5TqEkA@mail.gmail.com>
 <CA+RK=_C8FJ6OMBkww5bQJi6e284de1zOB9=Y7Zba4J-GtQ883w@mail.gmail.com>
 <CA+RK=_DWXaRuw2NS_Qab+=Hbu7Ryd+vv6h3+jYNd8mK6e5zFUQ@mail.gmail.com>
 <CADcMMgFUp+mC35rTDxcC1rkwxF+SX9QrjEwvspKAhirEw1X-sQ@mail.gmail.com>
 <CA+RK=_DZ0htMLq4Oqnp=6Cb4hd+DxsVTPRyFg+R9zUTRk175OQ@mail.gmail.com>
 <CALvzVW2jbLtEnJtpFOSspHwq5WYKN3eDvqAPLgU=bs0BM24VLg@mail.gmail.com>
 <CA+RK=_Daj=Wt95CR9T6NsJdNBtOEee5DjJv7k9sBQeCLGiJgGQ@mail.gmail.com>
 <CAMUu0w8VArsL=066t=5s3Z_YDjXqkbSbWKNHa3r5LAzU_g9wDA@mail.gmail.com>
 <CALvzVW2oXOpKjcQA654R3x+0DpTGcRTqz10O4a4csoY2K6mz-Q@mail.gmail.com>
 <CAMUu0w_ALdErGVqRNZDDtV7K+Kox-7qjz_Hn9Xx1YCyVosEUbg@mail.gmail.com>
 <CANZa=GuEV5DakwyD5rfRq8aTtXFTA25kAiS1K8nJxh4rAe57aA@mail.gmail.com>
 <CAG_TOPC2ZqkA5YA_Q4GwUNd5YDRgufPew7Kh-OLShSSOhfZnyg@mail.gmail.com>
From: Nick Dimiduk <ndimiduk@gmail.com>
Date: Tue, 30 Jul 2013 21:11:00 -0700
Message-ID: 
 <CANZa=GukCrd=c0vxke2nx2ajxstL8Q=oLuyqmaXPLrG2oqoECQ@mail.gmail.com>
Subject: Re: [UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 remaining
 issues
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=089e0102f010f7a70504e2c6ea9f

--089e0102f010f7a70504e2c6ea9f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 30, 2013 at 8:20 PM, James Taylor <jtaylor@salesforce.com>wrote=
:

> What's the functionality that we'll lose without the order-preserving par=
t
> being included?
>

Well, order preservation ;) Lacking 8201, we'd get all the existing Bytes
goodness but wrapped up in 8693's API. The framework is laid for other
HBase components, user applications, and downstream projects to start
building on it immediately. I'd like to start pluming it into some new
Filters, a couple of the MapReduce tools, Hive's interop layer, maybe even
replace PDataType with DataType if you're open to such a patch. The
OrderedBytes stuff will require applications to have a plan for data
migration when they decide to transition over to it, but they can get a
head-start on the boiler-plate code.

On Tue, Jul 30, 2013 at 5:39 PM, Nick Dimiduk <ndimiduk@gmail.com> wrote:
>
> > On Tue, Jul 30, 2013 at 3:28 PM, Enis S=C3=B6ztutar <enis.soz@gmail.com=
>
> wrote:
> >
> > > Let me elaborate. There are at least new RPC PB, PB structures in
> HFiles
> > /
> > > hlogs, and zk, table locks, bucket cache, online merge, stochastic LB=
,
> > > hbase on windows, *new data types*, AM changes, favorite node
> assignment,
> > > dist log replay, and tons of MTTR changes that are not run in
> production
> > so
> > > far.
> >
> >
> > Re: new data types, allow me to throw my hat into the ring as well. I
> spoke
> > with Stack this morning about a plan that I hope will allow the new dat=
a
> > type API to squeeze in without requiring the order-preserving encoding.
> I'd
> > like to get this API out with 0.96 so that users interested in adopting
> > this feature can start migrating their applications sooner than later.
> > Jealously, I want to start work on the Hive/HBase plumbing using this A=
PI
> > and the Hive guys are only willing to accept code that is built against=
 a
> > labeled HBase release. I'm hoping other projects (*cough* Phoenix,
> Impala,
> > Kiji *cough*) are keen to follow suit. It also allows for the feature t=
o
> > fan out internally -- Filters, Coprocessors, ImportTsv, &c. Using this
> > approach, DataType and Legacy* friends come in for 0.96.0 and
> OrderedBytes
> > can join the party in a 0.96.x when it's ready for adoption.
> >
> > Thanks,
> > Nick
> >
>

--089e0102f010f7a70504e2c6ea9f--