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/11 08:38:54 UTC
Is Avatica's ResultSetResponse's Signature field always present?
I have a bug report for the Go Avatica driver where someone executed an
`UPSERT` statement and caused the driver to crash. See
https://github.com/Boostport/avatica/issues/34
The driver crashed, because we tried to read
`ResultSetResponse.Signature` and it was null as the statement was an
upsert statement.
According to the protobuf documentation [0], signature is non-optional
and should always be present. Does this guarantee extend to data
modification statements like UPSERT?
Cheers,
Francis
[0]
https://calcite.apache.org/avatica/docs/protobuf_reference.html#resultsetresponse
Re: Is Avatica's ResultSetResponse's Signature field always present?
Posted by F21 <f2...@gmail.com>.
Thanks for clarifying! I've opened
https://github.com/apache/calcite-avatica/pull/10 to make this clearer.
Cheers,
Francis
On 12/07/2017 1:28 AM, Josh Elser wrote:
> There's one point I want to bring up first about "optional" fields.
> Every attribute on Avatica's messages are (should be) listed as
> optional. This is how we correctly handle a "drift" in the protocol
> itself. If we have fields marked as required, we would never be able
> to change them which may cause problems.
>
> It would probably be good to work towards tying docs to a specific
> version so we can remove this ambiguity :)
>
> To answer your question, no, there will be no Signature for
> INSERT/UPSERT operations (any operation which returns a number of rows
> affected instead of a ResultSet). For SQL which generate a ResultSet
> (some rows of data), the Signature would "always" be provided.
>
> On 7/11/17 4:38 AM, F21 wrote:
>> I have a bug report for the Go Avatica driver where someone executed
>> an `UPSERT` statement and caused the driver to crash. See
>> https://github.com/Boostport/avatica/issues/34
>>
>> The driver crashed, because we tried to read
>> `ResultSetResponse.Signature` and it was null as the statement was an
>> upsert statement.
>>
>> According to the protobuf documentation [0], signature is
>> non-optional and should always be present. Does this guarantee extend
>> to data modification statements like UPSERT?
>>
>> Cheers,
>>
>> Francis
>>
>>
>> [0]
>> https://calcite.apache.org/avatica/docs/protobuf_reference.html#resultsetresponse
>>
>>
Re: Is Avatica's ResultSetResponse's Signature field always present?
Posted by Josh Elser <jo...@gmail.com>.
There's one point I want to bring up first about "optional" fields.
Every attribute on Avatica's messages are (should be) listed as
optional. This is how we correctly handle a "drift" in the protocol
itself. If we have fields marked as required, we would never be able to
change them which may cause problems.
It would probably be good to work towards tying docs to a specific
version so we can remove this ambiguity :)
To answer your question, no, there will be no Signature for
INSERT/UPSERT operations (any operation which returns a number of rows
affected instead of a ResultSet). For SQL which generate a ResultSet
(some rows of data), the Signature would "always" be provided.
On 7/11/17 4:38 AM, F21 wrote:
> I have a bug report for the Go Avatica driver where someone executed an
> `UPSERT` statement and caused the driver to crash. See
> https://github.com/Boostport/avatica/issues/34
>
> The driver crashed, because we tried to read
> `ResultSetResponse.Signature` and it was null as the statement was an
> upsert statement.
>
> According to the protobuf documentation [0], signature is non-optional
> and should always be present. Does this guarantee extend to data
> modification statements like UPSERT?
>
> Cheers,
>
> Francis
>
>
> [0]
> https://calcite.apache.org/avatica/docs/protobuf_reference.html#resultsetresponse
>
>