[
https://issues.apache.org/jira/browse/THRIFT-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235560#comment-17235560
]
Allen George edited comment on THRIFT-5314 at 11/19/20, 4:02 PM:
-----------------------------------------------------------------
I don't think that's necessary. You could have the same outcome by using
something like:
{noformat}
pub enum RustEnum {
Add = 1,
Subtract = 2,
Multiply = 3,
Divide = 4,
__Unknown(i32),
}
{noformat}
After all, all we need is the ability to parse an unknown enum value on the
wire into a variant that can be processed by the receiving code. If
{{__Unknown}} is generated automatically the reading code can always populate
it with the unrecognized value on the wire.
was (Author: allengeorge):
I don't think that's necessary. You could have the same outcome by using
something like:
{noformat}
pub enum RustEnum {
Add = 1,
Subtract = 2,
Multiply = 3,
Divide = 4,
__Unknown(i32),
}
{noformat}
> 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)
