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 <[email protected]> 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, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
