phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: [DISCUSS] Handling missing HBase features/code across versions
Date Sun, 30 Jul 2017 20:07:04 GMT
Thanks for writing this up, Andy. In the spirit of this, I've
filed HBASE-18482.

On Wed, Jul 26, 2017 at 6:59 PM, Anoop John <anoop.hbase@gmail.com> wrote:

> Well said Andy.  Big +1
>
> -Anoop-
>
> On Wed, Jul 26, 2017 at 2:52 AM, Josh Elser <elserj@apache.org> wrote:
> > Thanks for the reply!
> >
> > On 7/24/17 9:52 PM, Andrew Purtell wrote:
> >>
> >> 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).
> >
> >
> > I like this as a path forward. I think I've had my head in the sand over
> the
> > feasibility of making stable API for Phoenix inside of HBase (ala
> > LimitedPrivate.HBase from Hadoop) -- your raise a good point as to why
> this
> > inevitably is flawed.
> >
> >> 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 think this works for that arbitrary point in the future, but what about
> > the time period until we get there? I read your underlying point as "do
> > nothing differently in Phoenix as our HBase version differences will
> > eventually go away", but I don't want to put words in your mouth.
> >
> >> 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.
> >
> >
> > Well, I'm sure there will be a number of us fretting when HBase-1.1 would
> > hit the chopping block after 0.98 goes ;)
> >
> >
>

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