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

David Reiss commented on THRIFT-446:
------------------------------------

Seems sensible.  I can think of a few complications.  First, you might need the 
mask to be recursive, since you might want to filter sub-objects.  Second, you 
would have to be sure that you used the same protocol for writing that you did 
for reading if you want to just forward the serialized data on.  I don't think 
that requires a new protocol interface, though.  
proto.getTransport().write(saved_data).  isset becomes a tr-state: set, unset, 
set-but-serialized.  Third, skipping over nontrivial requires a nontrivial 
amount of CPU.  Less than full deserialization, obviously, but nontrivial.

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

Reply via email to