thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John R. Frank" <>
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.

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

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,

View raw message