Nope, compatibility is still there..
The name of attributes in protobuf messages are irrelevant. The number
(3 or 5, in this case) are what guarantee correctness. Whether or not
you provide the first_frame_max_size as id=3 or id=5, the server will
parse the number accordingly and (should *wink*) do the right thing.
I am fairly positive I wrote some unit tests around this code.
On 7/17/17 5:57 AM, F21 wrote:
In CALCITE-1353, the first_frame_max_size was changed from a uint64 to
int32 because the value can be negative.
The change to the protobuf definitions can be seen here:
https://github.com/apache/calcite-avatica/blob/master/core/src/main/protobuf/requests.proto#L132
I've been making some updates to the Go driver and will be pulling in
the new protobuf definitions from the calcite-avatica source tree to
reflect this change.
From what I can see, does this mean backwards compatibility is broken?
Older clients will try to send a uint64 for the first_frame_max_size
field, but the server is expecting a int32. Newer clients will send a
int32, but an older server would be expecting a uint64.
What is the behavior if both deprecated_first_frame_max_size and
first_frame_max_size are sent to the server?
In this case, I'll probably bump a new major release for the driver to
communicate this backwards-incompatibility.
Francis
