Sanity Check for Protocol buffers

183 views
Skip to first unread message

CsabP

unread,
Jun 19, 2013, 5:08:48 PM6/19/13
to prot...@googlegroups.com
Hi All,

I'd like to extend protocol buffers by something like this:

message DateFormat {
  optional int32 year = 1 [default = 1970; min = 1970; max = 2010];
  optional int32 month = 2 [min = 1; max = 12];
  optional int32 day = 3 [min = 1; max = 31];
  repeated OtherMsg foobar = 4 [max_size= 10]; 
}

And in the generated code:

DateFormat msg;
...

// returns true if all members are between max and min
bool success = msg.sanityCheck();

// calculate the maximum size of the serialized stream:
int max_bytestream_size = msg.MaxByteStreamSizeIfSerializedToString();

I'm just wondering what could be the easiest way to do this? I'm not too familiar with the deep details of protobufs.
My first approach was to write a small parser in python which generates helper classes. But it's not very nice, maybe there is nicer solution available.

Thx for hints,

Csaba


Joel Holveck

unread,
Jun 20, 2013, 7:26:33 AM6/20/13
to prot...@googlegroups.com
If you want to extend Protobuf, then rather than writing a new parser, I would suggest that you use Protobuf's existing facility for custom options on FieldDescriptorProto.  See the description in https://developers.google.com/protocol-buffers/docs/proto#options , under "Custom Options".  You can then use protoc to call your custom code generator at the same time as it calls the stock Python code generator, by writing your code generator as a plugin; see https://developers.google.com/protocol-buffers/docs/reference/other .

That said, some people hold that serialization and data validation should be separate.  (There are different opinions about this, and good arguments each way.)  From that view, Protobuf may not be the best place to do data validation.  For example, the rules you give as an example would still allow a message with a date of 2000-02-31.  Data validation is often more complex than can be easily specified in the serialization schema, and should instead be in the class that holds the rest of your date logic.  Again, different people have different views on that philosophy, and also depends on different validation boundaries (e.g., what XML refers to as well-formed vs. valid).
Reply all
Reply to author
Forward
0 new messages