On 11/9/2015 at 11:32 AM, "Tom Deering" <[email protected]> wrote: > >Does Thrift have a solution for generating code with distributed, >versioned >dependencies (includes)? For example, suppose we have 3 >repositories with >Thrift definitions: > >*Foo:* Defines types, FooService. >*Bar (includes Foo):* Defines types, BarService extends FooService. >*Baz (includes Bar, Foo):* Defines BazService extends FooService, >uses >types in Foo, Bar. > >Suppose we want to generate code for Baz, which was written when >Foo and >Bar were at commits X and Y. Is there a standard way to express >pinned >Thrift dependencies and generate code with the necessary artifacts >at the >necessary versions? This is a solved problem for most programming >languages, but how about Thrift IDL? >
If you read section 5 of the Thrift whitepaper (https://thrift.apache.org/static/files/thrift-20070401.pdf), Thrift's versioning solution is outlined there. Generated code handles data definition changes robustly... there is a case analysis in there though that can alert you to the pitfalls. In summary your best bet is probably to implement default behavior for new fields when you update your servers. Don't remove fields if you can avoid it because new clients won't send the field when interacting with old servers that might not have a default behavior defined. To me, playing nice with Thrift's versioning solution is better than pinning to a specific version of an interface... if you need to do that though, you could simply change the namespace of your IDL to force clients to recompile. The other thing that comes to mind is to create a repository for the IDL dependencies you need in your version control system, and create a tag for the specific combination of versions that you need. Truthfully though, if you follow the strategy in the Thrift whitepaper, neither of these measures should be necessary. HTH Ben
