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 Mon, 10 Feb 2020 08:01:10 GMT
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