Thank you for starting this thread Istvan! This is really nice change and I can see how porting to 5.1 could be beneficial as well as disastrous for a maintenance release. One question: how confident are we from backward compatibility viewpoint? specifically 5.1 client against current master branch based server.
IMHO, we should keep this for major/minor release only. It would also enforce us to create 2 PRs going forward (one for master/5.2 and another for 5.1) but this is still better in case something gets broken in the future. Fixing it on maintenance release would also be nightmare. This is really good improvement. I also wonder what should be our path forward beyond 5.1. Shall we still stick to 5.2.0 or move to 6.0.0? master branch is becoming extremely heavy day by day with many features still being lined up for merging very soon. Json support is almost ready I believe. We have data integrity issues and many behavioural changes that are non-compatible (but necessary to implement heavy feature like ViewTTL) in the queue. Many committed features like Partial Index, Uncovered Index, MasterRegistry compatible JDBC connection etc are ready for rollout as soon as we cut release branch from master. It does seem quite a massive list for a minor release, but this is just my opinion. I am not against 5.2.0 release, would be open for more opinions. Thanks, Viraj On Mon, Dec 11, 2023 at 11:31 PM Istvan Toth <st...@apache.org> wrote: > Hi! > > First of all, a heads up that I have merged the Client-Server code > separation (PHOENIX-6053) patch a few minutes ago. > > A huge thanks to Aron for turning my two years old POC patch into a > merge-ready patch, and handling all the change requests and numerous > rebases. > > The patch has been discussed on the ticket > <https://issues.apache.org/jira/browse/PHOENIX-6053> > and in the 2021 > <https://lists.apache.org/thread/hs4klbc04n4gh62z17pznc0rkspjg6jx> and the > recent > <https://lists.apache.org/list?dev@phoenix.apache.org:2023-10:PHOENIX-6053 > > > email threads. > > > *A very quick recap:* > *phoenix-core* has been split into two modules* phoenix-core-client* and > *phoenix-core-server*. > *Phoenix-core-server* depends on* phoenix-core-client*, as we more or less > need the full client code on the server side. > phoenix-core includes all the code needed the JDBC driver, but does not > include anything that is used exclusively on the server side (coprocessors, > split policies, etc) > > *phoenix-core* is still around, it retains all the tests (as the majority > of them ), and it also acts as a compatibility dependency, which > transitively depends on both client and server. > > > *Backporting to 5.1:* > We need to make a decision on whether to backport this change into 5.1 or > not. > > Against: > > - It is a huge patch by file count > - maven module structure changes > > For: > > - Backports to 5.1 will be a *nightmare* if we don't backport this > change > - The actual code changes are minimal, and the behavioural changes > should be non-existent. > - Dependency compatibility should be handled by the phoenix-core package > - Users get the advantages without having to wait for 5.2. > > We have three options: > > - Backport to 5.1.4 > - Backport post 5.1.4 > - Do not backport > > > *I really need to hear your take on this.* > > *Next steps:* > This change in itself does little apart from cleaning up the code, but it > enables a number of important new features (these were originally planned > to be included in PHOENIX-6053, but I decided to split them to separate > tickets to keep the scope manageable): > > > - PHOENIX-7137 <https://issues.apache.org/jira/browse/PHOENIX-7137> > Create *phoenix-client-lite* shaded JAR without server-side dependencies > - This adds a new shaded client variant, *phoenix-client-lite *(names > are up for discussion), which omits the server-side code and its > dependencies. It is ~20 MB smaller, and pollutes the classpath less. > - PHOENIX-7139 <https://issues.apache.org/jira/browse/PHOENIX-7139> > Create *phoenix-mapreduce-byo-shaded-hbase* artifact for use by > connectors > - This allows using the hbase-shaded-client and phoenix on the same > classpath. Up until now, you had to do that by using the phoenix-core > dependency from Maven, or by using the HBase libraries shaded into > phoenix-client. > The current phoenix-client will fail hard with any other Hbase > libraries on the classpath due to relocation conflicts. > - Allows updating the hbase client code without rebuilding Phoenix > - Solves the protobuf 2.5.0 woes, which make it impossible to use > code/libraries using unshaded protobuf 3.0 together with > Phoenix. This was, > and remains the original driver behind PHOENIX-6053. > - Allows using Hadoop extensions with Phoenix. Being able to use the > various cloud connectors like AWS S3a without shading hundreds > of megabytes > of additional code into phoenix-client was another driver for this > change. > - This is the same shading setup already used by the shaded Hive and > Spark connector artifacts. > - Create a phoenix-client-byo-shaded-hbase which would be the same as > *phoenix-mapreduce-byo-shaded-hbase*, but omit the phoenix server-side > code. > - I'm on the fence about this. phoenix-mapreduce-byo-shaded-hbase > should be usable for this purpose. The server-side phoenix code > is not that > big, and *phoenix-mapreduce-byo-shaded-hbase *already omits any > server-side dependencies which could cause conflicts. > - Will need to run to see if this is needed / useful. >
