You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Mohammad Shahangian (JIRA)" <ji...@apache.org> on 2009/10/01 03:25:23 UTC

[jira] Updated: (THRIFT-446) Partial deserialization

     [ https://issues.apache.org/jira/browse/THRIFT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mohammad Shahangian updated THRIFT-446:
---------------------------------------

    Attachment: Thrift-446-v4.patch

Worked with Bryan to implement deserialization of specific structure in a Thrift Object. This increases the efficiency of deserialization by skipping expensive deserializaions(e.g. strings) and terminating inspection of fields once the object of interest is found. Follows same pattern as read function by iteratively iterating through fields but skips all fields except those included in the FieldIdPath. Fields that are in the FieldIdPath are "recursively" stepped into until the path is exhausted at which point read is called on that field.

Method was added to TDeserializer. Tests in PartialDeserializeTest.

> Partial deserialization
> -----------------------
>
>                 Key: THRIFT-446
>                 URL: https://issues.apache.org/jira/browse/THRIFT-446
>             Project: Thrift
>          Issue Type: New Feature
>            Reporter: Bryan Duxbury
>            Assignee: Mohammad Shahangian
>            Priority: Minor
>         Attachments: Thrift-446-v4.patch
>
>
> There are some use cases where you might have a fair amount of serialized data coming to you, but you're only interested in specific fields from that data. The way it works now, you are stuck paying the price to deserialize that extra data no matter what. 
> In the simplest approach, it would be nice if you could specify some sort of mask to use to suppress the deserialization of a given set of fields. A slightly more complex approach would be to not just skip the deserialization, but to actually hang on to the bytes that you didn't deserialize, so that when it came time to re-serialize, you could just rewrite the original data. 
> Obviously this would imply some interesting interactions with the validation system and probably nontrivial changes elsewhere (isset, protocol interface, etc). However, it could yield a big performance benefit in specific applications.

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