For the benefit of anyone else interested, this is the thread from Josh Elser on the Phoenix User mailing list:
Josh E
There would be significant "unwanted side-effects". You would be
taking on a very large burden trying to come up with a corresponding
client version of Phoenix which would still work against the newer
coprocessors that you are trying to deploy. Phoenix doesn't provide
any guarantee of compatibility for more than a few versions between
client and server.
Would suggest that you move to HDP 3.1.0 if you want a newer version of Phoenix.
me
Hey Josh, thanks for your thoughts.
Based on your advice we will almost certainly not pursue this direction. But just to clarify, in terms of the client version are you referring to the Query server, JDBC clients or both?
I imagine from the JDBC perspective that a client would only be accessing tables with the same Phoenix version. But it maybe that my take has a lot of erroneous assumptions in it, as I haven't looked at the internals of the JDBC driver code.
Josh E
I was referring to the JDBC (thick) client and the coprocessors inside
HBase. The thin JDBC client does not talk to HBase directly, only to PQS.
PQS and the thin-client would actually be the exception to what I said
in my last message. You could (with a high degree of confidence) deploy
a new version of Phoenix using an old thin JDBC driver. However, this
isn't really any different than just upgrading Phoenix wholesale.
Yup, in short, you're glossing over quite a bit. One example: the
(thick) JDBC must construct and send RPC messages to the appropriate
RegionServers to execute certain operations. The deployed coprocessors
in HBase must both know how to parse those RPC messages, but also
interpret them correctly (e.g. an older CP might be able to parse a
newer clients message, but could miss an important field that was added
to that message).
