hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jtay...@salesforce.com>
Subject Re: [UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 remaining issues
Date Wed, 31 Jul 2013 20:19:14 GMT
But the value in your patch is fixing the serialization format such that it
is order preserving. Unfortunately, without this, Phoenix can't adopt it.
It's existing type system and query processing is predicated on this.

On Wed, Jul 31, 2013 at 12:04 PM, Nick Dimiduk <ndimiduk@gmail.com> wrote:

> On Wed, Jul 31, 2013 at 10:31 AM, Stack <stack@duboce.net> wrote:
> > So what would be the incentive using the new API be?
> >
> Hopefully the new API is nicer than managing byte[]'s on manually. The only
> incentive for users would be keeping up with progress, giving users the
> chance to start migrating their applications. For the external tools, I'm
> looking forward to using this to make defining Hive tables over HBase
> nicer. The current column mapping stuff is clunky and this API gives a much
> improved mechanism for declaring column types. I can't do that without an
> API shipping with HBase. Maybe Elliott can weigh in on the Imapala side,
> James on Phoenix, Bueller from Kiji?
> And then when the implementation changes -- it serializes in sort-order --
> > will it confuse?
> >
> Let's continue my Hive example. Assuming DataType (9091 + 8694) ships in
> 0.96, Hive gets plumbed, and users get to start defining their tables in
> terms of LegacyInteger, LegacyBytesFixedWidth, and Struct. When the
> OrderedBytes patch (8201) comes in with it's type implementations, users at
> their leisure can drop the new types in when they're ready to transition.
> The Ordered* types don't replace the Legacy* types, they augment the
> catalog of types that HBase provides.

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