Re: [boost] [serialization] Support for multiple class name strings

In-Reply-To: <etctga$nvo$1@sea.gmane.org> ramey@rrsd.com (Robert Ramey) wrote (abridged):
I did something stupid with my serialization code. I blithely changed the names of several polymorphic classes everywhere they appeared in the code, since they had moved out of a class into that class's namespace (e.g. SomeNS::View::Primitive became SomeNS::Primitive). Several months later, I discovered that I could no longer read old binary archives, because I was using Boost.Serialization's BOOST_CLASS_EXPORT() macro, and this macro was now registering the Primtive type with the name-string "Primitive", instead of "View::Primitive", which is how it was saved in the oldest archives. would it be technically possible to add a BOOST_CLASS_EXPORT_ALIAS() macro, or some such? If it is possible, I'm willing to supply the implementation.
I might be possible by hacking your own copy of extended_type_info.hpp. I don't think we'd want to include such thing in the library.
Why not? I don't currently use boost serialisation so feel free to ignore me. I do use another library that uses class names for IDs, and I think some kind of aliasing or remapping facility is inevitably needed. In other words, if you support BOOST_CLASS_EXPORT() then you should also support BOOST_CLASS_EXPORT_ALIAS(). (I also think that using class names is a fairly good and natural way to get IDs.)
So I would suggest:
a) make the hack b) make small program which loads your old archives and creates new ones. This should be very easy. c) Forget this ever happened.
If by this you mean they should convert all the user data in one huge conversion binge, then that's not always practical. Sometimes the conversion has to be done inline, with the old archive format supported forever by all future version of the program. -- Dave Harris, Nottingham, UK.

Dave Harris said: (by the date of Mon, 19 Mar 2007 19:21 +0000 (GMT))
In other words, if you support BOOST_CLASS_EXPORT() then you should also support BOOST_CLASS_EXPORT_ALIAS().
If by this you mean they should convert all the user data in one huge conversion binge, then that's not always practical. Sometimes the conversion has to be done inline, with the old archive format supported forever by all future version of the program.
I agree 100%, because code refactoring is a very important aspect of software design. Even in the advanced stage, when the software is released and in production. Keeping backward compatibility _and_ being able to make code refactoring is a very big advantage. -- Janek Kozicki |

Dave Harris said: (by the date of Mon, 19 Mar 2007 19:21 +0000 (GMT))
In other words, if you support BOOST_CLASS_EXPORT() then you should also support BOOST_CLASS_EXPORT_ALIAS().
If by this you mean they should convert all the user data in one huge conversion binge, then that's not always practical. Sometimes the conversion has to be done inline, with the old archive format supported forever by all future version of the program.
I agree 100%, because code refactoring is a very important aspect of software design. Even in the advanced stage, when the software is released and in production. Keeping backward compatibility _and_ being able to make code refactoring is a very big advantage.
This is how I personally read the above statement: persistent identifiers used by a serialization library should be decoupled from C++ type names to limit invalidating file formats due to refactoring. I agree with Robert that supporting BOOST_CLASS_EXPORT_ALIAS is outside the scope of Boost Serialization. In my opinion, all you have to do to avoid having this problem is not use BOOST_CLASS_EXPORT in your header files, and instead register your classes manually. Technically speaking, BOOST_CLASS_EXPORT is guaranteed to work only if it's used in a compilation unit that is called explicitly: you can't rely on BOOST_CLASS_EXPORT to link the necessary serialization code just because you link a CPP file that uses BOOST_CLASS_EXPORT. Therefore the only thing automatic about this macro is that it uses the class name as persistent identifier of the class (which is the source of the problem at hand.) Emil Dotchevski
participants (3)
-
brangdon@cix.compulink.co.uk
-
Emil Dotchevski
-
Janek Kozicki