[ 
https://issues.apache.org/jira/browse/THRIFT-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845713#action_12845713
 ] 

Bryan Duxbury commented on THRIFT-735:
--------------------------------------

I don't think that using a type in a required field limits the flexibility of 
that type. It certainly limits the flexibility of the struct that uses that 
type - but that's fundamentally intentional. 

While you're right that adding a field in the RPC context is the same as 
"deleting" a field, again, this is only an issue if you are using required 
fields. If you say that a field is required, you are stating unequivocally that 
without some well-understood contents in that field, you can't work with the 
entire struct. If you plan to evolve your union fields or enum values, then you 
*must not use required fields*. I don't see how a well-meaning IDL coder could 
specify that a field is required and then be OK getting a null in some spot 
because you want to evolve elegantly.

Let's look at an RPC example. 

{code:title=client_side.thrift}

union MyResponse {
 1: string response_type_1;
}

service MyService {
  MyResponse someMethod(string blah);
}
{code}

{code:title=server_side.thrift}

union MyResponse {
 1: string response_type_1;
 2: string response_type_2;
}

service MyService {
  MyResponse someMethod(string blah);
}
{code}

With these two thrift files, how does it help the client to get back an unset 
union instead of a validation error? As far as the client is concerned, the 
result is unintelligible either way. At least if the validation works like I 
describe, they won't have to implement arbitrarily complex app-level validation 
to determine that they can't interpret the message.

> Required field checking is broken when the field type is a Union struct
> -----------------------------------------------------------------------
>
>                 Key: THRIFT-735
>                 URL: https://issues.apache.org/jira/browse/THRIFT-735
>             Project: Thrift
>          Issue Type: Bug
>          Components: Compiler (Java), Library (Java)
>    Affects Versions: 0.2
>            Reporter: Bryan Duxbury
>            Assignee: Bryan Duxbury
>             Fix For: 0.3
>
>         Attachments: thrift-735.patch
>
>
> The validate() method on generated structs verifies that required fields are 
> set after validation. However, if the type of the field is a Union struct, 
> then just checking that the field isn't null is not a valid check. The value 
> may be a non-null union, but have an unset field. (We encountered this when 
> deserializing a type that had a union for a field, and the union's set value 
> was an enum value that had been removed from the definition, making it a 
> skip.)
> In order to perform the correct validation, if the value is a Union, then we 
> must also check that the set field and value are non-null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to