[
https://issues.apache.org/jira/browse/THRIFT-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242620#comment-17242620
]
Jens Geyer commented on THRIFT-5314:
------------------------------------
{quote}
You refer to Thrift' "soft versioning" but I don't see how this relates to the
laxed treatment of invalid enum values in the cpp vs rust implementation.
{quote}
If you replace "invalid" by "possibly defined in the future" it makes a lot
more sense, does it? :-)
Why did I refer to soft versioning? Well, Thrift generally has very few limits
about what you cnando to evolve your Api contract represented as IDL files. You
may add new fields, methods, methiod arguments, data types and of course also
define additional services - all of this *whithout breaking the contract*. You
also can deprecate fields etc. with the only exception being "required", which
technically has a great potential to introduce breaking changes.
With all this in mind, why of all things and in whose interest woukd it be to
place a restriction on enums of the kind "thou may not add more, or remove
existing values from a given enum in the future". Hence, the implementation
should be absolutely able to deal with unknown enum values, because some
counterpart will send you such a value.
> 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)
