Re: [Boost-users] [Serialization : decending compatibility]Additionalattributes prevent de-serialization by previous

Subject: Re: [Boost-users] [Serialization : decending compatibility]Additionalattributes prevent de-serialization by previous
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-08-20 18:08:56

LOL - my motto is that no good deed shall go unpunished - here are some ideas:

for each class there is a
BOOST_CLASS_VERSION(myclass, version_number)
If this macro isn't included - its' the same as saying
BOOST_CLASS_VERSION(myclass, 0)

This version # is passed each time we serialize, save or load a class - that is:

template
save(Archive &ar, const unsigned version){
...
}

the "version" above contains the current value set by BOOST_CLASS_VERSION
for this class.

Current common practice is to include BOOST_CLASS_VERSION in each header

So the natural thing would be to have:

// archive_version_header

// type version for product version 0
#if product_version == 0
#define my_class_version 0
...
#elif product_version == 1
#define m_class_version 2
...
#endif

and in the header for my class to

...
BOOST_CLASS_VERSION(myclass,  my_class_version)

Finally, serialization function for my_class would
template
save(Archive &ar, const unsigned version){
    if(version > 1)
        // only do this if creating version 1 files.
    ....
}

So alll you have to do is include in ALL your headers

#define product_version 0 // 1, ... or pass it in the command line.
#include "archive_version.hpp"

So now you've done the whole job without changing the library!

almost ...

The missing pieces are:

a) this would require compilation of separate executable to create
"old style" archives.  Simple and efficient - but might not be convenient
depending on the application.  Addressing this would be quite a task

b) this doesn't address the fact that some types don't have versioning
for reasons of efficiency.  They only can be changed when the
global serialization library version is changed. Basically this applies
to stl collections included in the library.  So one would have to
make a funcition - set_library_version(int) to complement
get_library_version() and alter the code which depends upon
the archive version to produce the "old style" on request.  Doable
- but not trivial.

Anyway - food for thought

Robert Ramey

  "François Ramond" <francoisramond_at_[hidden]> wrote in message news:b7ed6cc70908201247x459f7770rdf203e81208ff9c5_at_mail.gmail.com...
  That's exactly the problem I'm facing... thanks! 

  From documentation : "A cursory examination of the code revealed that this would not be very difficult. It would require some small changes in code and some additional tests." -> I'll have a look at possible changes in the library code. Any hint of where to look to begin ?

  François

  On Thu, Aug 20, 2009 at 8:26 PM, Robert Ramey <ramey_at_[hidden]> wrote:

    This subject has been brought up before and it touched upon in the docmentation:

    libs/serialization/doc/todo.html#backversioning

    You might want to undertake this project.

    Robert Ramey

      <francoisramond_at_[hidden]> wrote in message news:001636eef81eefa4150471914868_at_google.com...
      Hello,

      I work on an industrial application which uses XML Boost Serialization as a way to store and retrieve production scheduling solutions from XML files. I've been using Serialization for years and I really enjoy the ease of use and the flexibility it provides.

      Recently, I released a new version (say V2) of that application, in which some C++ classes have additional attributes of new classes with respect to the previous version (V1). The new software (V2) can still read files serialized by the earlier version V1 (ascending compatibility), but XML files serialized by V2 cannot be read by V1. 

      I guess Boost Serialization wasn't designed for such "descending compatibility", nevertheless, during industrial production some unexpected bug on V2 might require to use V1 again (as it is stable), without loosing the scheduling solutions generated by V2. 

      From an XML file generated by V2, I somehow managed to remove the parts XML associated to the new attributes (the additional information can be skipped), and re-number some class_id to make the file readable by V1, but this is quite time-consuming, and I can't automate this process since the numbering of class_id depends on the solution serialized.

      Any idea to make V2 serialized files readable by V1, either by modifying V2 or by an automated process to edit the files (I can't bring any modification to the source code of V1) would be really appreciated.

      Thanks for reading till here and, hopefully, for your help,
      François 

--------------------------------------------------------------------------

      _______________________________________________
      Boost-users mailing list
      Boost-users_at_[hidden]
      http://lists.boost.org/mailman/listinfo.cgi/boost-users

    _______________________________________________
    Boost-users mailing list
    Boost-users_at_[hidden]
    http://lists.boost.org/mailman/listinfo.cgi/boost-users

------------------------------------------------------------------------------

  _______________________________________________
  Boost-users mailing list
  Boost-users_at_[hidden]
  http://lists.boost.org/mailman/listinfo.cgi/boost-users