[serialization] Writing an old version of a class
Hello Robert, hello all, I know it is stated in the boost::serialization library documentation that per definition always the latest version of a class goes to the archive. I wonder if there is a way to change this behaviour and choose the version number for my class at runtime. Obviously this feature would be useful in a system of two dependent modules where either the producer or the consumer could by updated to a newer version without the other one being neccessarily updated too. Maybe this has already been discussed but I could not find anything about it on the web. However my strong suspicion is that there is no such option within the library and I will have to provide a solution within the affected classes. Another thing: I specialize boost::archive::detail::heap_allocator<T> for my types to use my own memory management :-) Any objection to that? Finally I want to thank Robert Ramey for his fabulous library and his always timely and helpful answers. I think from the user perspective he stands as a positive example for others. Regards, -- Christian Pfligersdorffer EOS Software Engineering
Pfligersdorffer, Christian wrote:
Hello Robert, hello all,
I know it is stated in the boost::serialization library documentation that per definition always the latest version of a class goes to the archive. I wonder if there is a way to change this behaviour and choose the version number for my class at runtime. Obviously this feature would be useful in a system of two dependent modules where either the producer or the consumer could by updated to a newer version without the other one being neccessarily updated too. Maybe this has already been discussed but I could not find anything about it on the web. However my strong suspicion is that there is no such option within the library and I will have to provide a solution within the affected classes.
I dismissed this issue when it was recently brought up for the first time. I had never intended to provide an option for making "backward compatible" so I had presumed that it wasn't going to be possible. Well, some people kept bugging me and I did a little investigation and found that it would be quite possible with just a little bit of tweaking - and an amplified section in the documentation. So I guess it will be done with 1.35. FYI, the reason its doable is just a side effect of the fact that I leaned hard on "symetry" (I know I'm an atrocious speller) in order to conserve brain surface area. I suppose there is a lesson in there somewhere.
Another thing: I specialize boost::archive::detail::heap_allocator<T> for my types to use my own memory management :-) Any objection to that?
The truth is I never really considered issue related to custom allocators. I'm particularly interested in serialization of collections which use custom allocators. So I'm interested in any experience in this area.
Finally I want to thank Robert Ramey for his fabulous library and his always timely and helpful answers. I think from the user perspective he stands as a positive example for others.
I'm glad it's appreciated. But I should say that I really enjoy spending time on these kinds of posts. I guess its the smart persons alternative to internet chat forum. I would like to encourage those with questions/experience like this to get a little bit more involved in contributing to boost. Consider it therapy for a day job where you spend all day with brain dead managment and spend all your time hacking up the next fix because "we don't have time" to do it right. or... I would like to see more users contribute to demos/tests to the "case studies" section of the serialization documentation. A number of ideas have been presented on this list but I don't have time to persue them all. Here are a few. a) serialization of collections with custom allocators b) serialization of function objects c) automatic generation of an archive editor - (actually I've made progress on this myself) d) backward compatible archives - will require tweak in library but also special practice for serialization functions. e) composition with special stream buffers for increasing speed, implementing compression etc. What's in it for you? You get full authorship credit on your case study. It looks good on your resume. It makes you a part of the world's most exclusive club of C++ programmers. You get the satisfaction of knowing that you've done something "almost perfect". You get the satisfaction of knowing that perhaps thousands of other programmers know, use and appreciate your work. In short you get almost all the satisfaction that goes with being an "official" boost developer without the real pain (dealing with bjam, build, etc.) Rather than suffering a review process which is really frustrating, public and often unpleasant, you only have to pass one reviewer (me) in private. You get to interact with people who work with your code and get a chance to tweak it from time to time to fix bugs, clarify documentation, etc. In short you get most of the satisfaction of being a boost developer and avoid most of the pain. (Of course to get the full boost experience you have to undergo the full pain of a review and all the rest - but most people don't have the time for that) So there you are. Robert Ramey
Hello Robert! Robert Ramey wrote:
Pfligersdorffer, Christian wrote:
Hello Robert, hello all,
I know it is stated in the boost::serialization library documentation that per definition always the latest version of a class goes to the archive. I wonder if there is a way to change this behaviour and choose the version number for my class at runtime. Obviously this feature would be useful in a system of two dependent modules where either the producer or the consumer could by updated to a newer version without the other one being neccessarily updated too. Maybe this has already been discussed but I could not find anything about it on the web. However my strong suspicion is that there is no such option within the library and I will have to provide a solution within the affected classes.
I dismissed this issue when it was recently brought up for the first time. I had never intended to provide an option for making "backward compatible" so I had presumed that it wasn't going to be possible.
Well, some people kept bugging me and I did a little investigation and found that it would be quite possible with just a little bit of tweaking - and an amplified section in the documentation. So I guess it will be done with 1.35. FYI, the reason its doable is just a side effect of the fact that I leaned hard on "symetry" (I know I'm an atrocious speller) in order to conserve brain surface area. I suppose there is a lesson in there somewhere.
That's good news. I suppose it should be doable since everything you need is there - solely the option to pass a version number to the serialize functions. I wonder how you would add that feature without too many changes to the user interface. Since that relies on streaming operators maybe stream manipulators? Or archive member functions? I am interested in the details! :)
Another thing: I specialize boost::archive::detail::heap_allocator<T> for my types to use my own memory management :-) Any objection to that?
The truth is I never really considered issue related to custom allocators. I'm particularly interested in serialization of collections which use custom allocators. So I'm interested in any experience in this area.
Finally I want to thank Robert Ramey for his fabulous library and his always timely and helpful answers. I think from the user perspective he stands as a positive example for others.
I'm glad it's appreciated. But I should say that I really enjoy spending time on these kinds of posts. I guess its the smart persons alternative to internet chat forum. I would like to encourage those with questions/experience like this to get a little bit more involved in contributing to boost. Consider it therapy for a day job where you spend all day with brain dead managment and spend all your time hacking up the next fix because "we don't have time" to do it right. or...
I would like to see more users contribute to demos/tests to the "case studies" section of the serialization documentation. A number of ideas have been presented on this list but I don't have time to persue them all. Here are a few.
a) serialization of collections with custom allocators b) serialization of function objects c) automatic generation of an archive editor - (actually I've made progress on this myself) d) backward compatible archives - will require tweak in library but also special practice for serialization functions. e) composition with special stream buffers for increasing speed, implementing compression etc.
I might contribute our scenario which is serialization of command objects and for deserialization iterating over them using a custom allocator. Actually I think that would be fun although in the moment I am working to full capacity given my day-job and that paper I should be doing. So I will see what I can do during the next months and come back to you for it.
What's in it for you? You get full authorship credit on your case study. It looks good on your resume. It makes you a part of the world's most exclusive club of C++ programmers. You get the satisfaction of knowing that you've done something "almost perfect". You get the satisfaction of knowing that perhaps thousands of other programmers know, use and appreciate your work. In short you get almost all the satisfaction that goes with being an "official" boost developer without the real pain (dealing with bjam, build, etc.) Rather than suffering a review process which is really frustrating, public and often unpleasant, you only have to pass one reviewer (me) in private. You get to interact with people who work with your code and get a chance to tweak it from time to time to fix bugs, clarify documentation, etc. In short you get most of the satisfaction of being a boost developer and avoid most of the pain. (Of course to get the full boost experience you have to undergo the full pain of a review and all the rest - but most people don't have the time for that)
As I said, it sounds fun :) Regards, Christian Pfligersdorffer
Pfligersdorffer, Christian wrote:
That's good news. I suppose it should be doable since everything you need is there - solely the option to pass a version number to the serialize functions. I wonder how you would add that feature without too many changes to the user interface. Since that relies on streaming operators maybe stream manipulators? Or archive member functions? I am interested in the details! :)
Note that saving serialization functions also pass the class version number as parameter. This is set by the BOOST_CLASS_VERSION macro. The only thing that is necessary is to change that macro when one creates the output. Something like BOOST_CLASS_VERSION(T, VERSION_NUMBER_T) rather than BOOST_CLASS_VERSION(T, 4) and write template<class Archive> void save(Archive & ar, const T &t, const unsigned int version){ if(version < 4) ; // save the old way else ; // save the new way } just like in the load function. The only missing piece is for things like stl collections which don't use versioning (for speed) but rely on the global ArchiveVersion ofr the library. This global archive version is now a constant but will have to be "settable" to a lower number. Than's almost about it - except for the documentation and testing of course. Robert Ramey
participants (2)
-
Pfligersdorffer, Christian -
Robert Ramey