Set enum types as nullable

[GoogleCodeExporter]

Protobuffers is supposed to ignore fields on the wire that haven't been
defined for backwards compatibility.

A new (unknown) enum value, causes deserialisation to halt loosing the
entire message.  I think it would be better to set it to null.

---

Original issue reported on code.google.com by stuor...@gmail.com on 21 Jun 2009 at 10:54

[GoogleCodeExporter]

Can I clarify - it is a new enum *value* that is being the problem here, yes? 
(not a 
new enum field). I would need to check with the other implementations to see 
what the 
correct behaviour is here...

---

Original comment by marc.gravell on 21 Jun 2009 at 10:57

[GoogleCodeExporter]

Yes, a new value.

Loosing the contents of the other fields is undesirable for my particular app.

---

Original comment by stuor...@gmail.com on 21 Jun 2009 at 11:42

[GoogleCodeExporter]

From Kenton Varda:

It will be treated like an unknown field.  In C++ or Java, the value goes into 
the
UnknownFieldSet, so if you then serialize the message, it will still be there.  
In
Python it will just be discarded.

---

Original comment by stuor...@gmail.com on 24 Jun 2009 at 7:05

[GoogleCodeExporter]

I saw the discussion on the group ;-p

I'll see what I can do on the train tomorrow...

---

Original comment by marc.gravell on 24 Jun 2009 at 8:57

[GoogleCodeExporter]

Thanks Marc :)

---

Original comment by stuor...@gmail.com on 24 Jun 2009 at 9:17

[GoogleCodeExporter]

---

Original comment by marc.gravell on 26 Jun 2009 at 7:24

• Changed state: Started

[GoogleCodeExporter]

Just an update; working on it... easy to simply drop, but there are some issues 
with 
storing it in the extension layer...

---

Original comment by marc.gravell on 26 Jun 2009 at 8:03

[GoogleCodeExporter]

The issue I am having is that I have a server that routes proto messages from 
one
client to another.  It needs to deserialise that message to get the destination
route.  There is an enum value which describes the payload of message, so the 
client
can deserialise it correctly.

like this:

message packet
{
    required uint32   sourceID      = 1;
    required uint32   destinationID = 2;
    required enumType messageType   = 3;
    required bytes    payload       = 4;
}

The server doesnt care what the enum value is, but at the moment if it's not 
aware of
the enum, it fails deserialisation, and cant forward the message. Being able to 
read
underlying enum (wire) value would be handy.  Likewise, set the wire value for
serialsation.

---

Original comment by stuor...@gmail.com on 27 Jun 2009 at 2:13

[GoogleCodeExporter]

Well, as a pragmatic workaround (to get it working *now*)... have you 
considered:

    required uint32 messageType = 3;

and using the partial-class feature of C# to re-expose that as an enum property:

    partial class packet {
        public EnumType ActualMessageType {
            get {return (EnumType)messageType;}
            set {messageType = (int)value;}
        }
    }

i.e. internally it thinks of it as an int, but on the public C# API it thinks 
of it 
as an enum...

I'm working on the changes to support this properly; dropping the value is 
trivial - 
the tricky bit is storing it safely and allowing query. Most of that is there - 
I can 
work around the glitches. I would expect a "commit" of this at some point 
either this 
weekend or Monday - but I need to get off the computer before the wife brains 
me...

---

Original comment by marc.gravell on 27 Jun 2009 at 4:53

[GoogleCodeExporter]

Fixed r258; deserializes without setting property, but is available via 
Extensible.TryGetValue specifying "allowDefinedTag" as true (otherwise it 
demands that 
you use the property).

---

Original comment by marc.gravell on 29 Jun 2009 at 7:02

• Changed state: Fixed

[GoogleCodeExporter]

Thank you Marc, much appreciated.

---

Original comment by stuor...@gmail.com on 30 Jun 2009 at 9:12

[GoogleCodeExporter]

---

Original comment by marc.gravell on 30 Jun 2009 at 10:20

• Changed state: Accepted

[GoogleCodeExporter]

---

Original comment by marc.gravell on 1 Jul 2009 at 8:50

• Changed state: Verified