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 <st...@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 <gjac...@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 <els...@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 > st...@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/> > ------------------------------ >
