Thanks for the clarification Josh.
On Tue, 22 Jan 2019, 15:53 Josh Elser 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
>
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
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
Owen,
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
We are on HDP 2.6.5 but would like to use a more recent version of Phoenix,
without upgrading it cluster-wide.
HBase coprocessors can be dynamically deployed (for instance picking up the
coprocessor jar from HDFS) against specific tables. We are wondering
whether this would be a route to using a
