phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <>
Subject Re: [DISCUSS] Road to HBase 2.0.0
Date Tue, 17 Oct 2017 21:35:36 GMT
Some notes on this effort:

+ Perhaps this discussion should be cc'd to dev@hbase? There is a good bit
of overlap between dev-set here and dev-set on hbase and some
interest/concern around Phoenix on HBase2.
+ Here are some notes I took after looking at Phoenix last week that I ran
by James off-list (I filled in some of his feedback) [1]. The notes try to
list what Phoenix uses from HBase core. I was looking to Coprocessor usage
mostly. I noticed that CP-usage is mostly inside the bounds of appropriate
use. It is elsewhere that P is in violation.
+ After my splunking and going by feedback from James, do we have to carry
all of Phoenix over to hbase2? Can we drop some stuff that is not used
anymore or can we work out an ordained API P could use instead of do its
own workaround?

It is late in the day to be having this conversation -- we are about to
release alpha4 which is supposed to be locked-down internal and external
API -- but better late than never.


On Wed, Oct 11, 2017 at 3:00 PM, Josh Elser <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message