+1 James' plan is similar to what I had in mind. I think the quicker we
can get a branch in place to build against HBase2, the quicker we can
find and fix all of these rough edges.
Great list you have here, Sergey. Will certainly be helpful.
Ankit/Rajeshbabu, did you guys have anything to add here? Could I
encourage you to "run" with James' idea and start implementing some of
these changes?
On 10/13/17 6:28 PM, Sergey Soldatov wrote:
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
