[
https://issues.apache.org/jira/browse/THRIFT-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242671#comment-17242671
]
Z M edited comment on THRIFT-5314 at 12/2/20, 8:03 PM:
-------------------------------------------------------
[~jensg] thanks for your comments.
Wholly deprecating an 'optional' field makes perfect sense, as it was never
guaranteed to be included in a stream and its' presence can be inferred from
the stream.
Adding an enum value _without_ updating the stubs on both sides of the call
makes less sense to me.
How should an implementation decide whether an unrecognized enum value is a
value from a newer version of the IDL vs. just a corrupt data stream?
Following the logic of "possibly defined in the future", why then not just use
an i32 field, since any i32 will be "possibly defined in the future"?
The (semantic) point of an enum is to specify a subset of well defined
(semantically) values for a field, otherwise, why provide a set at all?
If I get an IP datagram where the 'Protocol' field in the header has some
unrecognized value (in that case the "enum" would be the relevant Protocol
values in the "Assigned Numbers" RFC) I don't expect my IP stack to silently
accept it.
was (Author: wiredwolf):
[~jensg] thanks for your comments.
Wholly deprecating an 'optional' field makes perfect sense, as it was never
guaranteed to be included in a stream and its' presence can be inferred from
the stream.
Adding an enum value _without_ updating the stubs on both sides of the call
makes less sense to me.
How should an implementation decide whether an unrecognized enum value is a
value from a newer version of the IDL vs. just a corrupt data stream?
If I get an IP datagram where the 'Protocol' field in the header has some
unrecognized value (in that case the "enum" would be the relevant Protocol
values in the "Assigned Numbers" RFC) I don't expect my IP stack to silently
accept it.
> Enum forward compatibility
> --------------------------
>
> Key: THRIFT-5314
> URL: https://issues.apache.org/jira/browse/THRIFT-5314
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Compiler, Rust - Library
> Affects Versions: 0.13.0
> Reporter: Remi Dettai
> Priority: Major
>
> It seems that enums in the Rust implem are not forward compatible. As Thrift
> enums are mapped 1:1 to Rust enum, if a newer Thrift definition adds a case
> to an enum, an error will be returned when parsing the message.
> Is this intended? Is there a workaround?
> (We met this problem in the Rust parquet implem:
> https://issues.apache.org/jira/browse/ARROW-10553)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
