thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Geyer (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (THRIFT-5314) Enum forward compatibility
Date Wed, 02 Dec 2020 18:59:00 GMT

    [ 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:58 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 *without 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 absolutely should be able to deal with unknown enum
values, because some counterpart will send you such a value some day.

> 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)

Mime
View raw message