Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
Thanks Marc :)
Original comment by stuor...@gmail.com
on 24 Jun 2009 at 9:17
Original comment by marc.gravell
on 26 Jun 2009 at 7:24
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
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
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
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
Thank you Marc, much appreciated.
Original comment by stuor...@gmail.com
on 30 Jun 2009 at 9:12
Original comment by marc.gravell
on 30 Jun 2009 at 10:20
Original comment by marc.gravell
on 1 Jul 2009 at 8:50
Original issue reported on code.google.com by
stuor...@gmail.com
on 21 Jun 2009 at 10:54