phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Istvan Toth <st...@apache.org>
Subject Re: Moving Phoenix master to Hbase 2.2
Date Thu, 23 Jan 2020 15:14:58 GMT
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 runtimes.

Please review and comment!

On Wed, Jan 22, 2020 at 12:41 PM István Tóth <stoty@cloudera.com> wrote:

> 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 can be converted to selecting
> the compatibility layer implementation at runtime, and have a single
> artifact.
>
> On Wed, Jan 15, 2020 at 6:22 PM Andrew Purtell <andrew.purtell@gmail.com>
> wrote:
>
>> 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 <zghaobac@gmail.com> wrote:
>> >
>> > 
>> >>
>> >>
>> >> 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 logic
>> to
>> >> the parent POM that chooses the right one. Then for each implicated
>> file,
>> >> move it into the version specific maven modules, duplicating as
>> needed, and
>> >> finally fixing up where needed.
>> >>
>> > +1. So we want to use one branch to handle all hbase branches? But we
>> still
>> > need to release multi src/bin tar for multi hbase versions?
>> >
>> > Andrew Purtell <andrew.purtell@gmail.com> 于2020年1月15日周三 上午10:55写道:
>> >
>> >> 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 method bodies can be factored into a class that groups together
>> static
>> >> helper methods which come to contain this common logic. The common
>> class
>> >> can remain in the core module. Then all you have in the version
>> specific
>> >> modules is scaffolding. In that scaffolding, calls to the static
>> methods in
>> >> core. It’s not a clever refactor but is DRY. Over time this can be made
>> >> cleaner case by case where the naive transformation has a distasteful
>> >> result.
>> >>
>> >>
>> >>> On Jan 14, 2020, at 6:40 PM, Andrew Purtell <andrew.purtell@gmail.com
>> >
>> >> wrote:
>> >>>
>> >>
>>
>
>
> --
> *István Tóth* | Sr. Software Engineer
> t. (36) 70 283-1788
> stoty@cloudera.com <https://www.cloudera.com>
> [image: Cloudera] <https://www.cloudera.com/>
> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image:
> Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera>
> <https://www.cloudera.com/>
> ------------------------------
>

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