phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Istvan Toth <st...@apache.org>
Subject Re: [DISCUSS] Unifying the 4.x branches
Date Wed, 19 Feb 2020 13:35:43 GMT
Now I have an unpolished version of the unified 4.x branch at
https://github.com/stoty/phoenix/tree/PHOENIX-5721

It takes the same approach as the  master branch, though there are a bit
more differences to hide in the versions.

I need to finish the assembly stuff, go over once more the changes, and run
full ITs on each profile, but I expect that
the Java code will mostly see whitespace changes, so you can check the
logic behind the changes.

The HBase metrics stuff in particular is interesting, because the whole
feature is missing from 1.3, so it can be used as an example on how we can
adopt new HBase features later.

On Mon, Feb 10, 2020 at 9:01 AM Istvan Toth <stoty@apache.org> wrote:

> Created PHOENIX-5721 <https://issues.apache.org/jira/browse/PHOENIX-5721> to
> track this.
>
> On Mon, Feb 10, 2020 at 8:21 AM István Tóth <stoty@cloudera.com> wrote:
>
>> Thanks for the feedback, Geoffrey.
>>
>> I took the lazy option of just creating compatibility methods to paper
>> over the HBase API changes (emulate the latest version) when we are calling
>> into HBase.
>>
>> For the APIs implemented by Phoenix, I added compatibility superclasses.
>> So I expect that we will be able to add a dummy RegionObserver.preWALAppend
>> to the compatibility coprocessor superclass(es), so that the same code
>> compiles for older versions as well.
>>
>> Of course if other code paths depend on having that functionality, those
>> should also be gated by similar compatibility shims/version checks.
>>
>> My current approach is a quick fix, and does not preclude (in fact it
>> enables) later efforts at refactoring/cleanup.
>>
>> On Fri, Feb 7, 2020 at 7:31 PM Geoffrey Jacoby <gjacoby@apache.org>
>> wrote:
>>
>>> If unification could be done, that would be great. (I apologize that I
>>> haven't had the bandwidth over the past week or two to take a close look
>>> at
>>> the work Istvan has been doing to unify the 5.x branches -- as one who
>>> spends too much time cherry-picking I very much appreciate this effort!
>>> :-)
>>> )
>>>
>>> I still think the hardest part, as I think I mentioned in some previous
>>> thread, is what to do when the HBase coprocs themselves diverge between
>>> minor versions, as they can do. How do you handle the fact that
>>> RegionObserver.preWALAppend exists in 1.5 but not 1.3 and 1.4, and will
>>> exist in 2.3 but not 2.2 and 2.1? And that therefore any features that
>>> depend on preWALAppend existing (none yet, but they're coming later this
>>> year) will work in a 1.5 or 2.3 environment, but not a 1.4 or 2.2 one?
>>>
>>> Since our coprocessors tend to be giant monoliths, trying to create
>>> release-based versions of them selectable by maven profile would
>>> either require lots of developer copy/paste for each change, or a
>>> significant (probably long overdue) refactor to make the coprocs small
>>> shims that call out to smaller, fine-grained classes that can
>>> occasionally
>>> be release-specific.
>>>
>>> Geoffrey
>>>
>>> On Fri, Feb 7, 2020 at 9:31 AM Josh Elser <elserj@apache.org> wrote:
>>>
>>> > Sounds like a good idea to me.
>>> >
>>> > On 2/6/20 8:40 AM, Istvan Toth wrote:
>>> > > Hello!
>>> > >
>>> > > Now that we have a working solution in master for handling different
>>> > HBase
>>> > > minor versions, I think that we should think about applying the same
>>> > > template to 4.x., and unifying the 4.x-HBase-1.3, 1.4, and 1.5
>>> branches.
>>> > >
>>> > > Are there any intentional differences between the branches, apart
>>> from
>>> > > having to conform to the slightly different APIs ?
>>> > > If there are, what are they, and are they considered blockers?
>>> > >
>>> > > Any other reasons not do this ?
>>> > >
>>> > > I expect that based on my experience with the master branch, I can
do
>>> > this
>>> > > in a few days, but I don't want to put in the effort if there is no
>>> > > interest in it.
>>> > >
>>> > > My plan is to take the 1.5 branch as a base.
>>> > >
>>> > > best regards
>>> > > Istvan
>>> > >
>>> >
>>>
>>
>>
>> --
>> *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