Cool, thanks James. It looks like our Abhishek is thinking along these lines too, see HBASE-18127.
On Sun, Jul 30, 2017 at 1:07 PM, James Taylor <[email protected]> wrote: > 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 ;) > > > > > > > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
