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
