leejw51 / protobuf-net

Automatically exported from code.google.com/p/protobuf-net
0 stars 0 forks source link

Serializing using given type rather than instance type. #197

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago

What steps will reproduce the problem?
1. Create an instance of SubClass
2. Serializer.Serialize<BaseClass>(stream, instance)
3. Only SubClass parameters are serialized.

What is the expected output? What do you see instead?
The BaseClass parameters should be included which they were not.
The SubClass parameters should not be included.

When the class BaseClass is Explicitly specified it should behave as if the 
object were of that class only, now it behaves as if <BaseClass> wasn't there. 
If this usage is not an expected one, then it should throw an exception.

I would wish for this approach to include parameters from both classes and 
merge them. Overlapping memberID:s should then cause an error.

What version of the product are you using? On what operating system?
v2 beta r404

Original issue reported on code.google.com by pe...@endnode.se on 27 Jun 2011 at 3:18

GoogleCodeExporter commented 9 years ago
Try:
http://stackoverflow.com/questions/6494577/expand-protobuf-message-with-subclass
/6497632#6497632

Original comment by marc.gravell on 27 Jun 2011 at 7:04

GoogleCodeExporter commented 9 years ago
Yes that is the same issue but I sent this bug to focus on the unexpected 
behaviour.

Specifically that you explicitly tell it to serialize as baseclass.

Serializer.Serialize<BaseClass>(stream, instance)

But it still get serialized as the subclass.

My biggest concern is that this was done silently. In my particular case the 
baseclass was a public key and the subclass was the public and private key. So 
it could have gone very wrong if not discovered.

I would have expected the method to at least throw an exception when the 
instance does not match the explicitly specified one.

Original comment by pe...@endnode.se on 8 Jul 2011 at 1:16

GoogleCodeExporter commented 9 years ago
If SubClass is marked (via ProtoInclude) as a known subtype of BaseClass, then 
it is ***not*** unexpected, even if you specify <BaseClass>. It is *entirely* 
expected, and indeed it is expected that it still serializes and serializes 
respecting inheritance. It is a fully supported use-case that you should be 
able to do:

    Animal animal = new Dog();
    Serialize<Animal>(animal);
    Animal copy = Deserialize();

and find that `copy` is in fact a Dog. Unless I misunderstand the scenario, 
this is no different.

Re flattening / overlapping fields; I don't think that is a good way to lay 
that data out.

Can you perhaps give a more specific/concrete example so that we can make sure 
we're talking about the same things here?

Original comment by marc.gravell on 8 Jul 2011 at 1:31

GoogleCodeExporter commented 9 years ago
Understood, I was expecting a behavior that was not intended.
You can mark this bug as Invalid/"by design".

Original comment by pe...@endnode.se on 8 Jul 2011 at 3:39

GoogleCodeExporter commented 9 years ago
Just to clarify I have included an example.
It does not use ProtoInclude, only c# class inheritance.

Original comment by pe...@endnode.se on 8 Jul 2011 at 4:02

Attachments:

GoogleCodeExporter commented 9 years ago
I'm going to keep this open to validate the full behaviour.

Original comment by marc.gravell on 8 Jul 2011 at 7:43

GoogleCodeExporter commented 9 years ago
I think there is a good use case for the requested behaviour:

Sometimes a derived class is used for implementation purposes, but only the 
base class is supposed to be public and exported. I have some OR mapping code 
where this is the case. I would like to serialize the "exportable" base type, 
and not the full (internal) derived class.

In the current implementation of protobuf-net I get an "unexpected sub-type" 
error when trying to serialize the sub-class as the base class, as I have 
intentionally not marked the sub-class with protobuf attributes. It would be 
useful to allow serialization as the base class if the sub-class is not marked 
for serialization.

Original comment by kwac...@gmail.com on 19 Apr 2013 at 12:47