phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: HBase 2.0 future integration.
Date Mon, 15 May 2017 03:17:49 GMT

Sergey Soldatov wrote:
> Hi,
> Well, HBase 2.0 will be released in the near future and we need to think
> about adopting Phoenix to it. I tried to do that and already feel
> uncomfortable with the amount of changes related to existing and potential
> problems. There are the list of problems I'm aware at the moment:
> 1. Deprecated API. No surprise that most of the deprecated 0.9x API was
> removed. Such as:
>     a. 'add' method for Put. We use it all across the code and tests.
>     b. HBaseAdmin replaced with Admin.
>     c. HTableInterface removed.
>     d. Public API should use Cell instead of KeyValue
>     e. Delete.deleteColumn =>  Delete.addColumn.
>     f. There are some other small changes that requires small modification
> (like .batch now requires             an array for the result instead of
> returning it)
> 2.  Due the shading stuff RPC callback need to use a new API
> from CoprocessorRpcUtils.
> 3.  No more "new HTable(...)". To get Table we have to create unmanaged
> connection and use .getTable.
> As for a potential problems:
> 1. new AM makes me worry in terms of the support for local indexes during
> split/merge.
> 2.  Tephra uses deprecated API as well, so it requires similar changes.
> So, here are my ideas :
> 1. start with something that we can change right now (API changes that
> would work with all supported versions of HBase) to minimize the work and
> amount of changes when 2.0 is released.
>   2. Decide what we are going to do with 0.98 support. Whether we plan to
> EOL it, or as an alternative we may create some kind of driver to HBase, so
> we will be able to keep all changes  for  different versions of HBase at a
> single place.

Dropping 0.98 support for Phoenix is the "obvious" idea to me to help 
move both projects forward.

I think if, in this process, we can identify areas in HBase which could 
use "firming up" WRT server-side stability, that would also be a welcome 

> Thanks,
> Sergey

View raw message