[
https://issues.apache.org/jira/browse/THRIFT-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242620#comment-17242620
]
Jens Geyer edited comment on THRIFT-5314 at 12/2/20, 6:57 PM:
--------------------------------------------------------------
{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 can do to evolve your API contract represented as IDL files. You
may add new fields, service methods, method arguments, exceptions, data types
and of course also define additional services - all of this *whithout breaking
the contract*. You can even deprecate fields etc. (with the only exception
being "required" fields - they technically have 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
absolutely should be able to deal with unknown enum values, because some
counterpart will send you such a value some day.
was (Author: jensg):
{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 can do to evolve your API contract represented as IDL files. You
may add new fields, service methods, method arguments, exceptions, data types
and of course also define additional services - all of this *whithout breaking
the contract*. You can even deprecate fields etc. (with the only exception
being "required" fields - they technically have 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)
