[jira] [Commented] (CALCITE-5558) avatica protobuf update_count and other signed ints should not be unsigned

["Julian Hyde (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697586#comment-17697586 ] 

Julian Hyde commented on CALCITE-5558:
--------------------------------------

Would this be a breaking change?

Update count never needs to be negative (except perhaps to store a 'not specified' value), so I don't feel strongly about whether it is stored in a signed or unsigned. I do acknowledge that it maps to a Java {{long}} (64 bit signed integer).

> avatica protobuf update_count and other signed ints should not be unsigned
> --------------------------------------------------------------------------
>
>                 Key: CALCITE-5558
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5558
>             Project: Calcite
>          Issue Type: Bug
>          Components: avatica
>    Affects Versions: avatica-1.23.0
>            Reporter: Martin Jonsson
>            Priority: Minor
>
> the update_count field of result set response in avatica is defined as uint64 which by default takes negative value -1.
> The protobuf specification states that negative values should use int or sint, not uint, since uint is... unsigned. For this reason many protobuf implementations can't handle uints that are negative. This might not be a terrible if you are building a client but I'm building a server based on avatica protobuf protocol and I would like it to work not just with standard java implementation and c++ implementation which seems to be the ones that handles this odd case.
> Would it be possible to change update_count from uint64 to int64? and same for all other possible negative ints currently defined as unsigned?
>  
> Many thanks
> Martin 
>   



--
This message was sent by Atlassian Jira
(v8.20.10#820010)