[date_time] bug with time_duration serialization moving from 1.32.0 to 1.33.1
Hi, we've been serializing data to binary archives since serialization was first released. As such we have collected a lot of data files. They are serialized using C++Builder 6 and boost-1.32.0. We're now looking to move to VS 2005 and as such, boost-1.33.1 seems a much easier solution than trying to get 1.32.0 to run. But I've had trouble de-serializing archives created with BCB6 and 1.32.0 with VS 2005 and 1.33.1. I've found the problem in time_duration serialization. Its serialization was changed between 1.32.0 and 1.33.1 but no version increment occured. As such, 1.33.1 can't read archives created with 1.32.0 because of this. A version could be added to 1.33.1 now to check for this, but I guess this would then break all archives currently written with 1.33.1. For us, we're trying to move to C# so I guess we will mostly be using boost for backwards compatibility for the foreseeable future so our solution is to add a #define to the 1.33.1 header that makes it behave like 1.32.0 did which enables us to load our files. But I'm not sure how you would solve this for other users or what to do before 1.34.0. This situation isn't ideal as can't think of a solution without breaking compatibility at some point. But as a last thought, please can people be careful when modifying serialization functions to keep backwards compatibility. This has taken quite a while to track down but that isn't nearly as scary as not being able to move forward to another version of boost without loosing the ability to load in all our customers data. Cheers Russell
Russell Hind wrote:
Hi, we've been serializing data to binary archives since serialization was first released. As such we have collected a lot of data files.
They are serialized using C++Builder 6 and boost-1.32.0.
We're now looking to move to VS 2005 and as such, boost-1.33.1 seems a much easier solution than trying to get 1.32.0 to run.
But I've had trouble de-serializing archives created with BCB6 and 1.32.0 with VS 2005 and 1.33.1. I've found the problem in time_duration serialization.
I see -- I take it this was the change that fixed serialization of special values: time_serialize.hpp 1.6 to 1.7?
Its serialization was changed between 1.32.0 and 1.33.1 but no version increment occured. As such, 1.33.1 can't read archives created with 1.32.0 because of this.
A version could be added to 1.33.1 now to check for this, but I guess this would then break all archives currently written with 1.33.1.
For us, we're trying to move to C# so I guess we will mostly be using boost for backwards compatibility for the foreseeable future so our solution is to add a #define to the 1.33.1 header that makes it behave like 1.32.0 did which enables us to load our files.
But I'm not sure how you would solve this for other users or what to do before 1.34.0. This situation isn't ideal as can't think of a solution without breaking compatibility at some point.
Well, I think at a minimum there needs to be a warning in the documentation. The only other obvious solution would be to provide a macro to allow the switchback to the old, broken, behavior. The other possibility I could see is to provide a macro which allows a program that takes the input the old format and the output the new format. This allows for creation of an archive conversion program and hence an upgrade path.
But as a last thought, please can people be careful when modifying serialization functions to keep backwards compatibility. This has taken quite a while to track down but that isn't nearly as scary as not being able to move forward to another version of boost without loosing the ability to load in all our customers data.
Thx for the report -- I clearly didn't understand the potential impact of this change. At a minimum there will be doc notes in 1.34. Jeff
Jeff Garland wrote:
Thx for the report -- I clearly didn't understand the potential impact of this change. At a minimum there will be doc notes in 1.34.
Thanks Jeff, we've gone the route of a #define that can enable the old 'broken' behavior for now. Adding a version 1 in for 1.34 could be a good idea and the #define for which behavior to use for version 0 time_durations (e.g. 1.32 or 1.33) could be a workable solution. Those who haven't upgraded to 1.33 yet just jump straight to 1.34 and would get the increased version and optional backwards compatibility. What do you think? Cheers Russell
participants (2)
-
Jeff Garland -
Russell Hind