phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From István Tóth <st...@cloudera.com.INVALID>
Subject Re: [DISCUSS] Unifying the 4.x branches
Date Mon, 10 Feb 2020 07:21:45 GMT
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