Serializing List of Objects

[Farooq Mushtaq]

How can we serialize list of objects by using protobuf-net? Is protobuf-net support list of objects like
public List(ABC) DEF
{
       get;
       set;
}

[Marc Gravell]

(note: this is specific to protobuf-net, not "protocol buffers" more widely), but yes: that (a generic list) would work fine, as long as the property has been marked for serialization and given a number. There also doesn't need to be a "set" accessor, although it can make full use of a "set" - i.e. if it finds the list is "null", it will create a new list of the appropriate type and use the "set" to update the object.

So, your code would be fine if it has been designated a number, or a related example:

    [ProtoMember(4)]

    public List<Order> Orders { get  { return orders; } } 

    private readonly List<Order> orders = new List<Order>();

Marc

(protobuf-net)

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/W0yySDcbES8J.
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

[Marc Gravell]

The data is of course compatible. A `List<Foo>` is directly mappable to .proto via for example:

    message SomeOuterMessage {

        repeated Foo items = 1;

    }

In fact, for that reason, serializing a List<Foo> will produce **exactly** the same data on the wire as serializing:

    [ProtoContract]

    public class Whatever {

        [ProtoMember(1)]

        public List<Foo> Items {get;set;}

    }

which is (give or take) what you will get if you feed the above .proto into "protogen" (protobuf-net's entirely optional code generator for handling .proto definitions)

Marc

On 27 June 2012 16:21, Joel Carrier <jo...@joelcarrier.com> wrote:

Hi Marc,

Could you elaborate on your note:  (note: this is specific to protobuf-net, not "protocol buffers" more widely) 

What are the implications if communicating with non-protobuf-net targets?  (ie. java, python, ... applications)

Joel

(protobuf-net)

To unsubscribe from this group, send email to protobuf+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

--
Regards,

Marc

--

You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/2pcXp7q9LCcJ.

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

[Joel Carrier]

Thanks a lot for the explanation Marc.

I'm currently investigating some interop issues we're having and I'm starting to realize that this might be the source of the problem.

 [CollectionDataContract(Name = "ItemList")]

 public class ItemList<TItem> : List<Item<TItem>> where TItem : class

...

where

    [DataContract(Name = "Item")]

    public class Item<TItem>  where TItem : class

    {

        [DataMember(Order = 1, Name = "Item")]

        public TItem Item { get; set; }

...

The TItems are classes generated from .proto files.  So we're mixing the functionality (annotated classes vs. proto files).

I think we're breaking a lot of "rules" here and I'm wondering how this could ever generate valid .proto files.

That is, if it were to work, I have trouble picturing what Serializer.GetProto<ItemList>() might output.

This does appear to be working between clients using protobuf-net but I guess what I'm looking for is confirmation that this would probably not work nicely interop-ing with other Protocol Buffer libraries.

(Note: I'm new to this stuff, so if I'm not making any sense at all let me know and I'll return with a smarter question.)

Joel

[Marc Gravell]

Well, until I get around to re-implementing it for v2, GetProto<T> will just make a quiet apology. But to answer your question, consider an example such as ItemList<Customer>

Item<TItem> could be (I can't remember how v1 implements this) something like

    message Item_Customer {

        optional Customer Item = 1;

    }

On the subject of ItemList<TItem>  - unless you disable list-handling (separate topic), this will be treated *entirely* as just a List<TItem> - so no specific message is generated. As per my previous comment, such a list is then semantically identical to

    message SomeWrapper {

         repeated Item_Customer Items = 1;

    }

Make sense?

Marc

To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/SUzHf4_n0O4J.

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

[Joel Carrier]

Yes it does.  Thanks.

Where can I read more about this disabling of list-handling and its effects?

[Marc Gravell]

Firstly, I must say that I don't generally recommend inheriting from lists in this context. The code, as an implementation detail, tries to detect things that look like lists, and switches to treat it as "repeated" data. Sometimes, pretty rarely, something *looks* like a list, but should be treated as an object. The important difference is that when handling a list it serializes the *contents* of the list - it doesn't look at the properties etc of the list itself. You can switch between the two modes via the IgnoreListHandling flag on either ProtoContractAttribute or MetaType.

Marc

--
Regards,

Marc