hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: [UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96 remaining issues
Date Wed, 31 Jul 2013 19:04:16 GMT
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