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
- Changes to first_frame_max_size in Avatica's ExecuteRequest F21
-
