Thanks, Josh!
I totally forgot protobuf fields are identified by their field numbers.
Francis
On 20/07/2017 4:32 AM, Josh Elser wrote:
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
