[
https://issues.apache.org/jira/browse/THRIFT-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681996#action_12681996
]
David Reiss edited comment on THRIFT-370 at 3/13/09 10:15 PM:
--------------------------------------------------------------
Jeremie is mostly right. This is the intended behavior. I would argue that it
is not Thrift being inconsistent between languages, but the languages
themselves having inconsistent data models. In C++ , the "normal" way to put a
field in a struct is just to make it a member (the memory for the field is
inside the memory for the struct). In Python (and Java for Objects), it is to
put a pointer to the field in the structure, giving the possibility of a null
value. We use those null values as a signal that the field is absent and
should not be sent on the wire. However, since C++ fields are not nullable, we
cannot make that determination. For optional fields, we use isset, but
maintaining isset manually is cumbersome, so we ignore it by default when
serializing. The primary use of isset is to determine whether the field was
present when it was read off the wire. In your example, the field was present
because the client sent the empty string. If the client had been in Java or
Python and the field had been null or None, then the server's isset would be
false.
was (Author: dreiss):
Jeremie is mostly right. This is the intended behavior. I would argue
that it is not Thrift being inconsistent between languages, but the languages
themselves having inconsistent data models. In C++, the "normal" way to put a
field in a struct is just to make it a member (the memory for the field is
inside the memory for the struct). In Python (and Java for Objects), it is to
put a pointer to the field in the structure, giving the possibility of a null
value. We use those null values as a signal that the field is absent and
should not be sent on the wire. However, since C++ fields are not nullable, we
cannot make that determination. For optional fields, we use isset, but
maintaining isset manually is cumbersome, so we ignore it by default when
serializing. The primary use of isset is to determine whether the field was
present when it was read off the wire. In your example, the field was present
because the client sent the empty string. If the client had been in Java or
Python and the field had been null or None, then the server's isset would be
false.
> unset fields in structs in c++ have __isset set to true
> -------------------------------------------------------
>
> Key: THRIFT-370
> URL: https://issues.apache.org/jira/browse/THRIFT-370
> Project: Thrift
> Issue Type: Bug
> Components: Library (C++)
> Affects Versions: 0.1
> Environment: Linux 2.6.27-11 x86_64
> Reporter: Nick Lanham
> Fix For: 0.1
>
> Attachments: issetTest.tar.gz
>
>
> If you have a struct like:
> struct test_struct {
> 1:string test_string
> }
> and then in a c++ client you do:
> test_struct foo;
> client.someFunc(foo)
> then the server will see it's argument (arg) as having
> arg.__isset.test_string set to true.
> similarly from the client side if expect a return value and do:
> test_struct returnVal;
> client.someFunc(returnVal);
> and the server does not set the returnVal to anything it will still see
> returnVal.__isset.test_string as true
> in all cases the string *is* set to the empty string as the constuctor for
> test_struct sets it, but __isset should not be true.
> Attached (should be) a simple test case. Just untar run "thrift --gen cpp
> isset.thrift" and then run make. start up the server and run the client to
> see the output.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
