You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by F21 <f2...@gmail.com> on 2017/07/17 09:57:43 UTC
Changes to first_frame_max_size in Avatica's ExecuteRequest
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
Re: Changes to first_frame_max_size in Avatica's ExecuteRequest
Posted by F21 <f2...@gmail.com>.
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
>>
>>
Re: Changes to first_frame_max_size in Avatica's ExecuteRequest
Posted by Josh Elser <jo...@gmail.com>.
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
>
>