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

Switch to Threaded View
HBase >> mail # dev >> [UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 remaining issues

Copy link to this message
Re: [UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 remaining issues
On Wed, Jul 31, 2013 at 10:31 AM, Stack <[EMAIL PROTECTED]> 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.