[
https://issues.apache.org/jira/browse/THRIFT-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242671#comment-17242671
]
Z M commented on THRIFT-5314:
-----------------------------
[~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)
