Skip to content

Don't use omitempty #3882

@safareli

Description

@safareli

Types which are generated from proto files in go have JSON annotations which contain omitempty for all keys, for example:

message ResponseInfo {
string data = 1;
string version = 2;
uint64 app_version = 3;
int64 last_block_height = 4;
bytes last_block_app_hash = 5;
}

Results in this:

type ResponseInfo struct {
Data string `protobuf:"bytes,1,opt,name=data,proto3" json:"data,omitempty"`
Version string `protobuf:"bytes,2,opt,name=version,proto3" json:"version,omitempty"`
AppVersion uint64 `protobuf:"varint,3,opt,name=app_version,json=appVersion,proto3" json:"app_version,omitempty"`
LastBlockHeight int64 `protobuf:"varint,4,opt,name=last_block_height,json=lastBlockHeight,proto3" json:"last_block_height,omitempty"`
LastBlockAppHash []byte `protobuf:"bytes,5,opt,name=last_block_app_hash,json=lastBlockAppHash,proto3" json:"last_block_app_hash,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}

Which means if you just make empty ResponseInfo{} and serialize it to JSON you would get empty JSON object, or if you do not set some field that field will be omitted from resulting JSON.

On the other hand, types defined by hand in go don't use omitempty at all, all this results in inconsistency. As some fields are in json all the time and some aren't, it makes writing parsers of request/response types unnecessarily harder in other statically typed languages.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C:abciComponent: Application Blockchain InterfaceS:proposalStatus: Proposal

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions