[
https://issues.apache.org/jira/browse/CALCITE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15328356#comment-15328356
]
Josh Elser commented on CALCITE-1287:
-------------------------------------
bq. Hi Josh, we have updated to a newer snapshot and are no longer seeing this
issue.
Great.
bq. We are sending parameters in base64 in string_value and receiving in
bytes_value since Phoenix 4.5. In the previous snapshot build, the server was
returning values with the `null` field set. After updating to the latest
snapshot, we are receiving data in both the string and bytes field and our test
cases pass.
Setting both string and bytes is what the server should be doing for backwards
compat (string is the b64 "unnecessary" way for old clients and bytes would be
the field to use going forward).
Thanks for getting back to me with your findings! I'll go ahead and close this
one as "Cannot Reproduce".
> Potential wire compatibility issue with binary data
> ---------------------------------------------------
>
> Key: CALCITE-1287
> URL: https://issues.apache.org/jira/browse/CALCITE-1287
> Project: Calcite
> Issue Type: Test
> Components: avatica
> Affects Versions: avatica-1.8.0
> Reporter: Josh Elser
> Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> Was chatting with [~kliew] today who mentioned that he thought there might be
> an issue with the wire-protocol with binary data ({{TypedValue.BYTE_STRING}}).
> avatica-1.8.0 did contain a change to how binary data was sent using
> protobufs (reported by [~francischuang] in CALCITE-1209, ultimately fixed in
> CALCITE-1103), but I believe this was done in a backwards compatible way.
> I just added a test to the TCK which shows that it is compatible with 1.6.0
> and 1.7.1, but maybe there is an edge condition I'm over looking (or the Java
> driver is masking).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
