Thanks for sending out the reminder, Istvan!
Those interested: please take a look ASAP or give a shout for more time
to review. On it's current trajectory, I think the PR will be in a place
to merge tomorrow (2020/02/05, US times).
On 1/30/20 2:49 PM, Istvan Toth wrote:
I have received a
I have received a ton of invaluable feedback from Josh, and some good
questions from Guanghao Zhang.
I am at the point where I am polishing the whitespaces and preparing to
update the documentation.
It would be great to hear some reviews from the SFDC side as well.
(even/especially if it is "this
I have updated https://github.com/apache/phoenix/pull/687
I consider this version mostly finished. (Still only for HBase 2.x)
I have abandoned the idea of a runtime compatibility solution, as the
all-important shaded thick client would become unmanageable with two
different HBase client
Hi!
In case not everyone on thread watches the ticket, I have put up a POC PR
for the build-time compatibility module solution.
It is for master/HBase 2.x. I did not investigate how well this approach
would fit incorporating HBase 1.x compatibility.
I also plan to investigate how easily this
I suppose so, but release building is scripted. The build script can iterate
over a set of desired HBase version targets and drive the build by setting
parameters on the maven command line.
> On Jan 15, 2020, at 2:01 AM, Guanghao Zhang wrote:
>
>
>>
>>
>> Anyway let’s assume for now you
>
> Anyway let’s assume for now you want to unify all the branches for HBase
> 1.x. Start with the lowest HBase version you want to support. Then iterate
> up to the highest HBase version you want to support. Whenever you run into
> compile problems, make a new version specific maven module, add
Take PhoenixAccessController as an example. Over time the HBase interfaces
change in minor ways. You’ll need different compilation units for this class to
be able to compile it across a wide range of 1.x. However the essential Phoenix
functionality does not change. The logic that makes up the
It’s not necessary to abstract the HBase interfaces into a compatibility layer,
at least not to start. At each bump from one minor release to another a fix up
typically touches a handful of files. The jump from 1.x to 2.x is a bigger deal
but maybe there should still be separate branches for
Still not having looked at what Tephra does -- I'm intrigued by what
Istvan has in-progress. Waiting to see what he comes up with would be my
suggestion :)
On 1/14/20 1:12 PM, la...@apache.org wrote:
Does somebody volunteer to take this up?
I can see whether I can a resource where I work,
Does somebody volunteer to take this up?
I can see whether I can a resource where I work, but it's highly uncertain.
It would need a bit of digging and design work to see how we would abstract the
HBase interface in the most effective way.
As mentioned below, Tephra did a good job at this and
Yes, the HBase API signatures change between versions, so we need to
compile each compat module against a specific HBase.
Whether I can define an internal compatibility API that is switchable at
run (startup) time without a performance hit remains to be seen.
István
On Tue, Jan 14, 2020 at 3:21
Agree that trying to wrangle branches is just too frustrating and
error-prone.
It would also be great if we could have a single Phoenix jar that works
across HBase versions, but would not die on that hill :)
On 12/20/19 5:04 AM, la...@apache.org wrote:
I said _provided_ they can be
A solution sounds great! Thanks for working on that.
By compile-time, I assume that means, unless we get lucky with
compatible bytecode, we'd have to have a Phoenix which is compiled
against a specific HBase version?
On 1/13/20 2:25 AM, István Tóth wrote:
Hi!
(Sorry for not replying
Hi!
(Sorry for not replying earlier, I'll need to revisit my mail filters)
I do have a half-baked patch with the lightweight isolation in modules case.
In its current form it's more ugly than complex, but some ugliness is a
small price to pay for not having to maintain multiple branches. (And
Yep that.
For the record... I do not think this is simple. But it is possible.
On Thursday, December 19, 2019, 8:37:37 PM GMT+1, Andrew Purtell
wrote:
I can't answer for Lars but whenever version incompatibilities come up
usually only a handful of files are impacted. In the last
I said _provided_ they can be isolated easily :) (I meant it in the sense of
assuming it's easy).
As I said though, Tephra has a similar problem and they did a really good job
isolating HBase versions. We can learn from them. Sometimes they isolate the
change only, and sometimes the class
I can't answer for Lars but whenever version incompatibilities come up
usually only a handful of files are impacted. In the last round, the
Phoenix access controller, a related file in the same directory, and the
RPC scheduler. If you cloned these into separate version specific maven
modules case
Lars,
I'm curious why you say the differences are easily isolated -- many of the
core classes of Phoenix either directly inherit HBase classes or implement
HBase interfaces, and those can vary between minor versions. (See my above
example of a new coprocessor hook on BaseRegionObserver.)
I've done a fair amount of porting Phoenix among HBase versions. There are
a couple of ways to pull out differences. If you take the rather
heavyweight approach HBase does where there's a factory for compatibility
glue, and a facade for the essential functions, and then instantiations of
that
Yep. The differences are pretty minimal - provided they can be isolated easily.
Tephra might be a pretty good model. It supports various versions of HBase in a
single branch and has similar issues as Phoenix (coprocessors, etc).
-- Lars
On Thursday, December 19, 2019, 7:07:51 PM GMT+1, Josh
To clarify, you think that compat modules are better than that
separate-branches model in 4.x?
On 12/18/19 11:29 AM, la...@apache.org wrote:
This is really hard to follow.
I think we should do the same with HBase dependencies in Phoenix that HBase
does with Hadoop dependencies.
That is: We
This is really hard to follow.
I think we should do the same with HBase dependencies in Phoenix that HBase
does with Hadoop dependencies.
That is: We could have a maven module with the specific HBase version
dependent code.
Btw. Tephra does the same... A module for HBase version specific
What do you think about tying the minor releases to Hbase minor releases
(not necessarily one-to-one)
for example (provided 5.1 is 2020H1)
5.0.0 -> HB 2.0
5.1.0 -> HB 2.2.2 (and whatever 2.1 is API compatible with it)
5.1.x -> HB 2.2.x (treat as maintenance branch, no major new features)
5.2.0
Since HBase 2.0 is EOM'ed, I'm +1 for not worrying about 2.0.x
compatibility with the 5.x branch going forward.
Given how coupled Phoenix is to the implementation details of HBase though,
I'm not sure trying to abstract those away to keep one Phoenix branch per
HBase major version is practical,
As much as possible, I'd like to avoid us getting into another situation
with 5.x where we have multiple branches. My hope was/is that we can
keep one Phoenix5 branch that works against an acceptable set of HBase
branches.
To me, that acceptable set of HBase branches is _a_ 2.1 and 2.2
Hi!
I'd like to start a conversation about supporting HBase 2.2. in the
master branch.
https://issues.apache.org/jira/browse/PHOENIX-5268 has a slightly out of
date, but functional PR for HBase 2.2 support on master. (Please review
and comment if you have the time, I'll try to update the PR in
26 matches
Mail list logo
