Re: [boost] Serialization and dynamic "fallback" to base classes

From: Edgars Irmejs (edgars_at_[hidden])
Date: 2007-12-07 17:55:03

> > Boost Serialization library provides a great solution for
> serializing
> > derived classes by pointers to base classes, but I'm concerned
> with a
> > simple use case:
> > The program is being used on two computers "A" and "B" where "A"
> sends
> > data to "B" by the means of serialization. At some upgrade of the
> > program a serialized class "bus" is complemented with a derived
> class
> > "big_bus". Only computer "A" gets the new version. I don't want
> the
> > old version on "B" to dismiss a received "big_bus" object from
> "A", I
> > need to convert it into a "bus" class object. It is sometimes
> much
> > more useful to process the "big_bus" as a "bus" than not to
> process
> > at all.
>
> > I can assure serialization of each derivation starts with the
> > serialization of the base class. I'm also ready to cope with the
> > overhead of storing parent class information within the
> information
> > about the derived classes. And it's ok if multiple inheritance is
> out
> > of the question.
>
> > Is there a pattern, a proposed solution to allow this dynamic
> > "fallback" to base classes?
>
> Currently the library will throw and "unregistered class"
> exception.
> Personally, I would prefer to spend my effort in making sure this
> never happens rather than trying to accomodate it in someway.
> BUT, you're not me so the question remains.
>
> I think all you need is in there.
>
> a) Handle the thrown exception in a more elaborate way.
> b) Only polymorphic base class pointer serialize their derived
> classes.  If you just make sure your classes don't have
> any "virtual" functions and you only serialize through the
> base class, there would be nothing to do.
> c) You could use class versioning to recognise that
> the current version is greater than the version which
> was used when the application was built.
> d) Already there are boost/variant and boost/optional
> serializations in the library.  They might be of use here.
>
> Those are the ideas that come into my head in the
> time alloted.
>

Those classes are polymorphic by a major design decision and just as
you said - I am serializing by base class pointer. It seems a bit
harsh to destroy that polymorphism for the sake of serialization.
That makes b) impractical.
Ideas in a), c) would be really nice if there were just a "bus"  and
"big_bus" in the real life. In fact, I have a big tree of small
classes all derived from one base class. So I was hoping for a system
which would allow to "fallback" to the closest known parent. Thus I
also don't see how d) helps.

As during the lifetime of the boost/serialization you seemingly hadn't
been asked a question like mine, I suppose I'm facing a quite specific
problem. So I'll probably just stick with making sure that the
software gets updated everywhere.

I've always liked to maintain as much as possible old versions of
software for users who don't want to upgrade. That includes not
destroying their existing functionality (receiving "bus" class
objects). Maybe it's just plain wrong...

Thanks anyway!