[
https://issues.apache.org/jira/browse/THRIFT-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Armaan Sarkar updated THRIFT-1239:
----------------------------------
Attachment: thrift-1239-v3.patch
I made the following changes:
1. The default fields are now handled like optional ones.
2. The fixtures use the setter/getter methods instead of directly accessing the
fields. This was messing with the isSet checks.
3. The result_writer method delegates to the scheme, just like the regular
struct writer methods. This was messing with the serialization test.
4. Now that the Tuple protocol is getting the same test treatment as the other
protocols, I removed redundant test cases from TestTTupleProtocol.
> TupleProtocol- An extremely compact, temporary protocol
> -------------------------------------------------------
>
> Key: THRIFT-1239
> URL: https://issues.apache.org/jira/browse/THRIFT-1239
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Compiler
> Reporter: Armaan Sarkar
> Priority: Minor
> Attachments: pluggable_serializer_master.patch, thrift-1239-v2.patch,
> thrift-1239-v3.patch, tuple_generator.patch, tuple_protocol.patch
>
>
> Currently, protocols are built to be pretty robust to 'schema' changes. This
> is done by sending metadata about when a struct or a field will start/end,
> the number of fields to expect and the types of each field, etc. However,
> there are cases when the recipient knows all of this, even before it receives
> this metadata. In these cases, sending the metadata unnecessarily eats up
> bandwidth. The TupleProtocol rectifies this by sending and receiving only the
> value of each field in a specified order. The only metadata passed is about
> variable information such as the size of a container or which optional fields
> are set.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
