thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John R. Frank" <...@mit.edu>
Subject Re: updating to longer ints
Date Thu, 14 Mar 2013 18:39:07 GMT
> The Thrift "way" would be to create a new field for the i32 field, say 
> 101.
>
> In other words, the logic that you propose, would have to be handled at 
> the application layer.

To enable that application layer, there would have to be two differently 
names properties on Thing, like idx and idx32

This raises a bigger question:  versioning.

The real form of our Thing is this public interface, which has a 
"Versions" struct that is used today just for debugging.  I wish I could 
use it for more.

https://github.com/trec-kba/streamcorpus/blob/master/if/streamcorpus.thrift

We use these thrift interfaces to store this large public data set of 
text:

         http://s3.amazonaws.com/aws-publicdatasets/trec/index.html

Right now, any program that uses the streamcorpus.thrift interfaces must 
be told by the user whether it is processing v0_1_0 or v0_2_0.  Soon there 
will be v0_3_0 to cope with our picking i16 when we needed i32 for 
MentionID.  We do re-spin the entire corpus occassionally, but we prefer 
to save up changes and spend a CPU-decade on several changes at once.

It would be really helpful/powerful for thrift to handle such versioning 
for us.  Most simply, there could be a thrift primitive at the level of a 
whole message that says "I am version X", where the engineer gets to 
specify X in the .thrift file.

At a more granular level, versioning could be used to enable falling back 
to different meanings for properties with the same name -- probably with 
different slot numbers and types.

Does anything like this exist yet?

Would the Thrift community be open to considering such a feature?  Maybe 
this has already been discussed?

Thanks for listening,
jrf




Mime
View raw message