Well said Andy. Big +1 -Anoop-
On Wed, Jul 26, 2017 at 2:52 AM, Josh Elser <[email protected]> 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 ;) > >
