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
