Thanks for sending out the reminder, Istvan!
Those interested: please take a look ASAP or give a shout for more time
to review. On it's current trajectory, I think the PR will be in a place
to merge tomorrow (2020/02/05, US times).
On 1/30/20 2:49 PM, Istvan Toth wrote:
I have received a ton of invaluable feedback from Josh, and some good
questions from Guanghao Zhang.
I am at the point where I am polishing the whitespaces and preparing to
update the documentation.
It would be great to hear some reviews from the SFDC side as well.
(even/especially if it is "this is great, carry on!", or a +1 :) )
It is likely that the very same approach could be used for unifying the 4.x
branches,
so that we'd end up with two development branches,
instead of the current four, which would be a huge win for maintainability.
On Thu, Jan 23, 2020 at 4:14 PM Istvan Toth <st...@apache.org> wrote:
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 <st...@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.purt...@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 <zghao...@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.purt...@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.purt...@gmail.com>
wrote:
--
*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/>
------------------------------
