0

I am currently developing a gRPC service in Go with gRPC Gateway as an HTTP proxy. I am generating .pb.go bindings from my .proto files, but I noticed that there are subtle changes to my bindings in two separate but related situations when I wouldn't expect it. Each binding file has a mysterious field var fileDescriptorX = byte[]{.....} where X is actually a number. Both unexpected changes happen with this field and only this field.

My big question: Are these bindings compatible with each other or are changes to this field considered breaking changes, rendering different versions of the bindings incompatible?

First, if I add another proto file to the same folder and it comes alphabetically before the existing protos, the fileDescriptor field will be renamed when I re-generate my Go bindings. The number X at the end of the name of the field fileDescriptorX corresponds to its ordering compared to the other files in the folder. To be clear, if I have a folder with b.proto and b.pb.go, then I add a.proto and then re-reun my compiler to create a.pb.go, b.pb.go's file descriptor will get bumped from 0 to 1, and a.pb.go will get the new filedescriptor0.

Second, since I am using gRPC gateway, I wanted to change the paths in my HTTP options. Let's say I have an RPC in a.proto:

rpc GetFoo(GetFooRequest) returns (Foo) {
    option (google.api.http) = {
        get: "/v1alpha1/foo"
    };
}

When I change the path above to "/api/foo/v1alpha1/foo", a.pb.gw.go changes understandably, but the bytes in a.pb.go's fileDescriptor0 field change as well.

There doesn't seem to be any documentation discussing how these fields are used and if changes in them are incompatible, breaking changes with other bindings. Any help is appreciated. Thanks!

4

1 回答 1

1

These "file descriptors" are actually binary encodings of everything in your .proto file. The format is defined by descirptor.proto in the Protobuf source code. Any change you make to your .proto files is expected to cause the file descriptors to change.

This isn't documented because this is an internal implementation detail of the generated code. You don't need to worry about what's changing in the generated code. As long as your .proto changes follow the documented backwards-compatibility rules, your protocol will be compatible.

于 2018-08-22T03:12:50.547 回答