Question

I have a struct that I am putting into my thrift interface for clients to pass various pieces of metadata to the server (version info, client identifiers, things that would normally go in HTTP headers).

I would like this to always be the last argument to every service method. My thought is that I can define methods like this:

void Foo(1: i32 argA, 2: string argB, 10: myStruct trackingData)

This way, if I add another field I can still add it in the middle:

void Foo(1: i32 argA, 2: string argB, 3: i32 somethingNew, 10: myStruct trackingData)

Will this scenario cause backward or forward compatibility problems with clients in the even that we need to add new parameters in the middle?

Was it helpful?

Solution

Yes, it is perfectly ok.

Best practice: If you find at some point in time, that you may no longer need a particular (non-required) field, only comment it out in the IDL file, do not delete it. This way it is clear that the number has been used once and should not be re-used again, risking compatibility issues otherwise.

A good read is Diwaker Gupta's Missing Guide.

OTHER TIPS

It's OK, as JensG answered.

For developers who really care about the message size, coming from Protocol Buffers it is useful to know that in Thrift there's no general rule such as in protobuf that tags with values in the range 1 through 15 take one byte to encode [..] Tags in the range 16 through 2047 take two bytes..

This is because Thrift offers a range of encodings (JSON, binary, binary compact, ...), depending on which the byte size of the encoded index may or may not vary. In JSON for example, numbers between 10 and 99 would take up one byte more than numbers between 0 and 9. In the standard binary encoding however, the encoded size is the same for all indexes. For the compact binary protocol, it again makes sense to use lower index numbers if you care about message size (which you probably do, when choosing compact).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top