[
https://issues.apache.org/jira/browse/THRIFT-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242708#comment-17242708
]
Yuxuan Wang commented on THRIFT-5314:
-------------------------------------
[~WiredWolf] so enums can be considered as "documented i32 constants" in some
way. on the wire they are the same as i32s, but they also come with values
documented, so you don't have to use magic numbers in your code.
If a server removed an enum value the client is still using, the server should
either return an error indicate that the client passed in an unsupported enum
value, or silently ignore it if the enum value is truly optional. This is the
same as any optional fields being absent: a lot of practical usage of
thrift/protobuf are that they define every field as optional so removing them
in the future is not a breaking change, but some of those fields are actually
required (at the time being) and if it's absent server will just return an
error to the client.
> 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)
