3

Application A uses a this proto file

message The_message
{
   enum The_enum
   {
      one = 1;
      two = 2;
   }

   required The_enum the_enum = 1;
}

Application B uses the next version of the file. It is similar except that it has one more enum field

three = 3;

What happens if Application B sends a message to Application A using the three enum?

The protobuf documentation says

if you try to provide a different value, the parser will treat it like an unknown field

So the enum three becomes an unknown field. Which would be fine if the_enum were optional, but it is a required field.
Will Application A be able to parse the message correctly?
Are enums not meant to be extended this way?

Timwi
  • 65,159
  • 33
  • 165
  • 230
deft_code
  • 57,255
  • 29
  • 141
  • 224
  • 2
    The answer will likely be different between C# and C++, I don't know about Java though. – M.Babcock Dec 30 '11 at 03:14
  • Presumably `null` in Java, as enums are genuine objects. (Never used protocol buffers.) – Tom Hawtin - tackline Dec 30 '11 at 03:33
  • Have you tried it? The documentation is unclear so I would take that as 'try it yourself and see what happens' though it will likely result in @StephenC's answer below. – M.Babcock Dec 30 '11 at 03:36
  • @M.Babcock my particular use case is a C++ and C# application talking to each other. But there is no reason it couldn't be talking to a Java application. I'm looking for the behavior of the protocol, not the behavior of a particular implementation. It may be undefined, which would be fine (I then know I can't portably extend required enum definitions). – deft_code Dec 30 '11 at 03:49
  • 1
    Related: http://groups.google.com/group/protobuf/browse_thread/thread/66ca3bbd2d09845d/4157dc66074d9a94?lnk=gst&q=Enum+unexpected#4157dc66074d9a94 – Marc Gravell Dec 30 '11 at 09:06
  • @MarcGravell, that is exactly the answer I was looking for. It's basically what Stephen C said but with a source instead of just conjecture. – deft_code Dec 30 '11 at 16:09

1 Answers1

3

I'd expect the parser to behave the same way as if it encountered a message in which a required field was missing. I'd expect the parser to reject the message.

The page you linked to says this:

Required Is Forever - You should be very careful about marking fields as required. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field – old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally.

Now this isn't exactly the scenario you are talking about, but it implies that missing required message will cause the message not to be accepted.


If the enum-typed field was not required, then the documentation implies that the field would be treated as an unknown field. If you were using a version of the protobuf API that supported it, you could access this field / value, but you'd see it as bytes or something, and not as the mapped Java or C# enum type.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216