There is a list of problems that we need to fix to get it working with HBase 2.0: 1. renamed methods (such as add => addColumn). That's the easiest to fix 2. removed interfaces such as HTableInterface. We are supposed to use Table now. That may lead to some small difference between branches. Because that's funny, but there are some HBase 1.x methods are using deprecated API, but have no duplicated methods that appears only in 2.0. The same thing with KeyValue => Cell if I remember correctly. 3. Our wrappers for HTable/etc. Since the set of methods sometimes very different for 1.x and 2.0, we will need to maintain different versions. Luckily that's one time work and maintaining would not be hard because we rarely change them. 4. Some renaming would be required. I can recall KeyValueUtil, possible some else to avoid ambiguity between our and HBase classes. 5. signature some of methods has been changed. Like batch() now doesn't return the result, but requires it as an argument 6. Many methods switched from using byte[] to TableName. Don't remember, but possible that works fine with 1.x, so it can be part of (1) refactoring. 7. new Coprocessors. I have no idea how many changes we will have, because my previous attempts to get it working with HBase 2.0 were far before new implementation.
I support the roadmap provided by James. Most of the changes I listed (300+K patch) can be done as the first bullet in his list. Thanks, Sergey On Fri, Oct 13, 2017 at 2:40 PM, James Taylor <jamestay...@apache.org> wrote: > One idea of where to put the code: > - switch to using non deprecated HBase methods in master > - same for Tephra > - create a 5.0-HBase-2.0 branch to put code specific to getting Phoenix to > work against HBase 2.0 > - take a look at the changes and see if a shim layer makes sense (I'm only > -1 on an HBase 0.98 shim layer because the life span of that branch is very > limited) > - eventually make 5.0-HBase-2.0 the master branch > > Thoughts? > > On Fri, Oct 13, 2017 at 8:31 AM, Josh Elser <els...@apache.org> wrote: > > > Thanks, Anoop! > > > > I know Sergey, Ankit, and Rajeshbabu have been looking at this already. > > > > While tracking it is good, I think we still need to come up with a plan > > for where we're going to put that new code in Phoenix :) > > > > > > On 10/13/17 6:58 AM, Anoop John wrote: > > > >> Thanks for bringing this up. I was abt to ask this. Ya the CP > >> framework itself and the CP exposed interfaces (Like > >> RegionServerServices, Region etc) are undergoing a big change for for > >> HBase 2.0.. I did a look at some of the usages of the Phoenix > >> exposed interfaces/classes. There are some items for fix. Was > >> thinking to raise an umbrella issue once we have a plan for the > >> version based on HBase 2.0 > >> > >> -Anoop- > >> > >> On Thu, Oct 12, 2017 at 3:30 AM, Josh Elser <els...@apache.org> wrote: > >> > >>> Since 4.12.0 is out and we have the concurrent discussions about the > >>> 0.98, > >>> 1.1, and 1.2 HBase branches, do folks have a vision of how we get to > >>> HBase > >>> 2.0.0? > >>> > >>> The lack of chatter is pretty obvious that the Calcite work (the > previous > >>> impetus for Phoenix 5) has slowed. Once we get to an HBase > 2.0.0-alpha4, > >>> coprocessor API should stabilize and give us a point against which we > can > >>> start Phoenix work. > >>> > >>> Should a release of Phoenix that supports HBase 2.0 be worthy of the > >>> Phoenix > >>> 5.0 label, or should we stick to the 4.x numbering? Given the breaking > >>> changes going into HBase 2.0 and James' previous -1 to shim-layers for > >>> 0.98, > >>> do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a > >>> different > >>> beast? I can see pros/cons for both sides. > >>> > >>> - Josh > >>> > >> >
