[protobuf-net] Class hierarchy serialization

[Gulnor]

Hi,

I have the following class hierarchy:

public class AbstractMessage {}
public class GetAll<T> : AbstractMessage {}
public class GetAllCars : GetAll<Car> {}

I'd like to serialize GetAllCars and deserialize it as an
AbstractMessage. Is that posible at all?

Thanks.

[Marc Gravell]

What implementation are you using? Given that most of the
implementations use code-generation (rather than reflection), I'm
wondering if this is protobuf-net?
(since that supports inheritance by representing it as nested
messages).

Marc

[Kenton Varda]

Note the subject line -- it's protobuf-net.  :)

[Marc Gravell]

> Note the subject line -- it's protobuf-net.  :)

I see "Class hierarchy serialization" using google-groups.
(ahhh - if you expand "More options" you see the full "[protobuf-net]
Class hierarchy serialization" - interesting!)

OK - to expand:

protobuf-net supports class hierarchies, which is does by representing
subtypes as nested messages (to make it wire compatible), with a bit
of magic thrown in. What it *doesn't* currently support is the open
generic type (GetAll<T>) in the middle of the stack. This is in part
because you need to declare the metadata that it uses to identify
subtypes in the type defintion.

Without the open type, then yes - it is fine:

[ProtoContract, ProtoInclude(1, typeof(CarMessage))]
class AbstractMessage {...}

[ProtoContract]
class CarMessage : AbstractMessage {...}

Now, regardless of whether you use CarMessage or AbstractMessage when
using Serializer, it will identify the correct type. So if you
serialize an AbstractMessage you will get back an AbstractMessage; if
you serialize CarMessage (as either an AbstractMessage or a
CarMessage) you will always get back a CarMessage (regardless of
whether you ask for an AbstractMessage or a CarMessage).

If there is a good use-case for supporting open generic types, then
that approach *might* fit into the work I'm currently doing that lets
you specify the model separately to the main class definitions. It
wasn't on my plan (and it would have to wait a little bit until I've
completed the current refactor), but it could *potentially* work -
*if* there is a good scenario for it...

Marc Gravell

[Gulnor]

(Hmmm, today I can't see the [protobuf-net] that I added to the
subject.)

I knew about that option, actually, my app is using that approach. I'm
using protobuf-net with WCF, keeping existent [DataContract]/
[DataMember] attributes, and have a base class AbstractMessage with
some common information.

I have some CRUD operations that are common to a lot of entities in my
app, so I ended up creating some generic messages GetAll<T>, Edit<T>,
Save<T>, Validate<T>, etc... That's the use case I have, but I don't
know if its general enough to be added to protobuf-net.

By the way, I've made some changes to source code (from rev 250). If
you like a patch to review it or more information, pls let me know
(maybe some change is useful for someone else).

Thanks for the excellent job you are doing with this library, Mark.

[Marc Gravell]

Re the "[protobuf-net]" - it seems to be a glitch in google groups. It
is there (see "More options" for the top message) - it just doesn't
appear!

Feel free to send me a patch (marc.g...@gmail.com). Note that I've
got a big branch in progress, so I'd probably need to re-implement it
for the refactored code, but that isn't a problem. What does the patch
add/fix?

Marc