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 <[email protected]> wrote: > 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 ;) > > > > >
