Serializing Dictionary<string,object>

NYCBrit

unread,

Jan 29, 2011, 11:03:08 AM1/29/11

to Protocol Buffers

Is it possible to serialize a Dictionary<string,object> where all the
objects are pointing to classes marked up with [ProtoContract]?

Marc Gravell

unread,

Jan 31, 2011, 1:06:14 AM1/31/11

to NYCBrit, Protocol Buffers

I assume you mean with protobuf-net there; in which case, no.

Because protobuf-net follows the general protobuf spec, there is no type-specific metadata that would allow me to encode/decode an arbitrary object, or to store the details of which type of object is stored.

Marc (protobuf-net)

On 29 January 2011 16:03, NYCBrit <richa...@gmail.com> wrote:

Is it possible to serialize a Dictionary<string,object> where all the
objects are pointing to classes marked up with [ProtoContract]?

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

--
Regards,

Marc

Miguel Muñoz

unread,

Jan 31, 2011, 2:25:00 PM1/31/11

to Protocol Buffers

The way we serialize a map<String, String> is this:

1) We define a MappedPair message like this:

message MappedPair {
string key=1;
string value=2;
}

2) Then we define a MappedPairList message, that's just a repeated
MappedPair.

3) Then we iterate through our Map<String, String> to convert it to a
MappedPairList, and serialize that.

Since you're mapping serialized objects, your task is a bit more
difficult, but I'm sure there's a way to do it.

-- Miguel Munoz

Marc Gravell

unread,

Jan 31, 2011, 3:02:48 PM1/31/11

to Miguel Muñoz, Protocol Buffers

Actually protobuf-net will handle IDictionary<TKey,TValue> *fine* as long as both TKey and TValue make sense to protobuf-net, and it treats them (exactly like in your example) as fields 1 and 2 respectively. I suspect you could also use anything implementing IEnumerable<KeyValuePair<TKey,TValue>> under the same conditions. In v2 I add support for non-generic collections, so you could probably handle things like StringDictionary right off the bat (although I'll be honest - I haven't specifically tested with StringDictionary)

Marc

2011/1/31 Miguel Muñoz <SwingG...@yahoo.com>

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

--
Regards,

Marc

Richard Geary

unread,

Jan 31, 2011, 8:58:53 PM1/31/11

to Marc Gravell, Protocol Buffers

What sort of restrictions are in the Google protobuf spec? Is this possible as a user-extension of the protobuf-net library? eg. Could I create an object surrogate, serializing the name of the derived type as a string, then dynamically read/write the type to the stream based on the type string? Or does the spec make this not possible because it forces a static message structure?

Thanks!

Marc Gravell

unread,

Feb 1, 2011, 3:13:36 AM2/1/11

to Richard Geary, Protocol Buffers

Both, really. And of course by the time you are embedding **type** metadata into the file you have ceased to be portable (or contract-based). This is potentially something that could be added as a non-portable feature of a single implementation, but *in most cases* there are ways to do it **inside** the portable spec, and I'd rather push people towards using portable options unless there is no feasible alternative.