phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <>
Subject Re: [DISCUSS] Handling missing HBase features/code across versions
Date Tue, 25 Jul 2017 01:52:48 GMT
As a coprocessor application there is no way not to be bogged down in
internal details. Coprocessors are by definition mixin extensions to
internal HBase code. Compatibility discontinuities are going to be a  fact
of life. All coprocessor APIs are LimitedPrivate. This is weaker than
Public. I don't think anyone in HBase wants to break Phoenix intentionally
but it could happen.

What I would advise is whenever undertaking a major new task or feature do
the following:

1a. Survey HBase code for supported (Public,LimitedPrivate) interfaces that
will allow you to accomplish the task

1b. If HBase does not provide a Public or LP interface that will allow you
to accomplish the task, implement that interface and submit the patch for
same to the HBase project for commit. JIRAs like this without a patch are
unlikely to get much traction. When the back and forth is done and the
final patch is committed, and it is committed to all shipping versions of
HBase, you have a foundation upon which to build. This is not something
Phoenix has traditionally done and has suffered as a result (IMHO).

2. Implement the Phoenix feature

3. Never use interfaces marked as Private. If one of them seems ideal as a
supportable interface, go to line #1b above.

I also recommend dropping support for older HBase code lines as quickly as
possible. The first to go should be 0.98. It is overdue since the EOL
announcement this past January. This came up recently in another thread and
my thought was it will be fine to do this in a few months, for what it's
worth, but this position is partly self-interest in that our production is
still trying to lift off of 0.98. If Phoenix dropped support for 0.98 that
would be fine with me actually. We could carry ourselves over the gap.

On Fri, Jul 21, 2017 at 3:40 PM, Josh Elser <> wrote:

> Hi all,
> James raised a good question on PHOENIX-3598 surrounding how Phoenix
> should handle the case when a specific version of HBase that Phoenix uses
> is lacking/missing some kind of code/functionality.
> For example, I wrote some test cases which set-up a minicluster with
> Kerberos. HBase 0.98 and 1.1 never got this code, so the tests (obviously)
> don't run on those branches.
> What do people think about managing the support-ability and divergence
> across all multiple branches?
> What should the bar for a change in Phoenix be? (must be supported in
> against all HBase versions? OK to be missing in some versions?)
> If a feature is missing or implemented differently in certain versions,
> how do we advertise that to users?
> Meta: is this a sustainable model for the Phoenix project? How can we
> (continue) to make our life easier in growing Phoenix without getting
> bogged down in the HBase implementation details. (obligatory: I know many
> great folks have been long fighting this up-hill battle. I don't intend to
> throw shade on those efforts, just acknowledge that we still have a way to
> go and it would help to prioritize it).
> - Josh

Best regards,

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

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