Re: [Boost-users] [serialization] class versioning changesin boost 1.42

Subject: Re: [Boost-users] [serialization] class versioning changesin boost 1.42
From: David Raulo (david.raulo_at_[hidden])
Date: 2010-02-25 15:47:23

On Thu, 25 Feb 2010 08:49:50 -0800
"Robert Ramey" <ramey_at_[hidden]> wrote:

> Vladimir Prus wrote:
> > Robert Ramey wrote:
> >
> > Well, I assume that most folks who use Boost.Serialization don't
> > post here to report what version scheme they have used. So, I
> > suggest you don't make broad conclusions based on the number of
> > reports.
> 
> I would expect that people running across problems with the scheme
> would post here.  So I think it's correct that this hasn't been a
> problem up until now.

Maybe we are the only ones to use big version numbers, maybe not. In
the later case these users will only get bit when they switch to boost
1.42. So it may be a little early to judge.

> The signature for loading is:
> 
> void load(Archive & ar, T & t, const version){

Maybe it would be a good idea to change this signature to reflect the
actual contract on version numbers, so new users can not miss it.

> in addition, there is a serialization library version returned
> with get_library_version.  This is used internally by the
> library to address changes in serialization of primitives
> and other types for which class information is not kept
> in the archive.  I believe that this version # is now up to 4.

Did this number change with boost 1.42?  If yes I could use it
to detect these archives and work around my problem.

> Their usage of the version number presumed a 32 bit
> integer.  binary archives only use 16 bits.  So their change would
> make it impossible for them to use binary archives.

Actually, we did encounter this problem with binary archive early on,
and we found that binary archive stored the class version as 8
bits (not 16). I guess I should have posted about this then. But this
was not a regression (AFAICT binary archives always behaved like this),
and it made sense that in a binary format you may want to save every
last byte. So we switched wo XML, and did not report about it here
since we assumed to be safe.  I understand now that you did not
anticipate our usage.

About binary archives, I just did a test, and with boost 1.42 we now
get an exception:

/opt/boost-1_42_0/include/boost/archive/basic_binary_oarchive.hpp:83:
void boost::archive::basic_binary_oarchive<Archive>::save_override(const
boost::archive:\ :version_type&, int) [with Archive =
boost::archive::binary_oarchive]: Assertion `t.t <=
boost::integer_traits<unsigned char>::const_max' failed.

and this is while saving an object with version 300 to a binary archive
(100 works as expected).  With an xml archive, and a version number of
100000, no exception, and the version is truncated to 16 bits.

> > Assuming the use classes are not changed, why program built with
> > 1.41 cannot read archive created by 1.42?
> 
> It can.

Not in my case.  That's how I initially discovered the problem. The
class version properties in XML archives generated by 1.42 were
truncated to 16 bits, and so could not be read back (with either 1.41
or 1.42).

> In this particular case, the situation is that a program built with
> 1.42 cannot read an archive created by 1.41

yes, and I understand that.

BTW there is still something I do not understand here.
Here is an archive generated with boost 1.42 :

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="7">
<vec class_id="0" tracking_level="0" version="0">
        <count>2</count>
        <item_version>100000</item_version>
        <item class_id="1" tracking_level="1" version="34464" object_id="_0">
                <value>1</value>
        </item>
        <item object_id="_1">
                <value>1</value>
        </item>
</vec>
</boost_serialization>

This is an STL vector of objects having BOOST_CLASS_VERSION(100000).
The class version is truncated, but the "original" number appears as the
item_version just above. How did that happen? Is there any way I can
access this item_version ?

Thanks for your help,

David.