Created protoDocument from proto.Message preserves generated XXX_* fields.

[hosaka]

Cross posting from firebase/firebase-admin-go#228 as suggested by @hiranya911

Hello,

• Operating System version: Ubuntu 18.04.2 LTS
• Firebase SDK version: 3.6.0
• Library version: _____
• Firebase Product: (auth, storage)

Steps to reproduce:

I am looking for a quick protobuf to firestore push, without fiddling with json or string maps in go. Reading the code I saw that data interface{} can be a struct or a pointer to a struct, passing the pb.Message works perfectly fine, however it also serializes the generated XXX_ fields in my pb.go file. Please see the code for a quick example.

Is this left as is on purpose or perhaps it's an oversight?
Thank you in advance!

Relevant Code:

message Note {
    int32 Id = 1;
    int32 GroupId = 2;
    int32 LocationId = 3;
    int32 OwnerId = 4;
}

func (s *storeService) RegisterNote(ctx context.Context, in *Note) (*StoreResponse, error) {
	client, err := app.Firestore(ctx)

	_, _, err = client.Collection("notes").Add(ctx, in)

	return &StoreResponse{Success: true}, nil
}

[jeanbza]

cc @mikelehen @schmidt-sebastian

[jeanbza]

Is this left as is on purpose or perhaps it's an oversight?

This seems to be intentional, AFAICT. structToProtoValue grabs all fields from a struct and creates a map out of it. I don't think it's a good idea for us to be building protobuf-aware code, so I lean towards keeping it this way. If you'd like to omit these fields, I'd consider serializing it to whatever form that you prefer.

Note that this problem should disappear after golang/protobuf#276.

[hosaka]

@jadekler Thanks for the heads up. I do understand that protobuf-aware skips will just increase the amount of work in the future. It's not a huge issue, as I don't mind just leaving those fields in, they introduce little overhead in the grand scheme of things. I will keep an eye on that PR.

[jeanbza]

Sounds good! 👍