Re: [Boost-users] [serialization-1.32.0] de-serializing newer versions that the application can deal with
[sorry for breaking the threading, just re-joined the list]
We have system data written out to an XML archive and being de-serialized at application startup.
One object type in the archive we written at version 1 by a newer version of the application. We then ran an older version of the software which only understood version 0 of the object.
Hi Russel, To handle different versions of data you should split serialize() into separate save()/load() functions as described in the tutorial: http://boost.org/libs/serialization/doc/tutorial.html#splitting The implementation will look something like: void save(...) { // Serialize all data here } void load(Archive & ar, unsigned int version) { if (version > 0) { // Load data added in version 1 } if (version > 1) { // Load data added in version 2 } // Load version 0 data } Regards, -- Tarjei
Tarjei Knapstad wrote:
To handle different versions of data you should split serialize() into separate save()/load() functions as described in the tutorial:
http://boost.org/libs/serialization/doc/tutorial.html#splitting
I understand that. That isn't the issue I'm describing. The issue I'm describing is that the application *only* knows about version *0* of an object, but the file contains version *1* because it was written with a newer version that it is being loaded with. Cheers Russell
On Thursday, June 15, 2006 at 17:01:57 (+0100) Russell Hind writes:
Tarjei Knapstad wrote:
To handle different versions of data you should split serialize() into separate save()/load() functions as described in the tutorial:
http://boost.org/libs/serialization/doc/tutorial.html#splitting
I understand that. That isn't the issue I'm describing. The issue I'm describing is that the application *only* knows about version *0* of an object, but the file contains version *1* because it was written with a newer version that it is being loaded with.
Versioning is per-class, and so why would you increment the version if you did not introduce forward-incompatible changes? It seems that you only increment the version if you add/remove data members, reorder them, or whatever. I don't really see a practical downside to having the library automatically puke if you are using old code to read a newer version of a class. Bill
Bill Lear wrote:
Versioning is per-class, and so why would you increment the version if you did not introduce forward-incompatible changes? It seems that you only increment the version if you add/remove data members, reorder them, or whatever. I don't really see a practical downside to having the library automatically puke if you are using old code to read a newer version of a class.
I don't expect the old version to read it successfully. The 'puke' as you put it at the moment is an access violation. Which basically may have left the process in an unstable state. I want it to 'puke' but with an exception that can be caught and handled gracefully. Not an access violation which basically means its anyones guess as to whether the software can run successfully. Read my original post on the matter again. Cheers Russell
On Friday, June 16, 2006 at 08:45:27 (+0100) Russell Hind writes:
Bill Lear wrote:
Versioning is per-class, and so why would you increment the version if you did not introduce forward-incompatible changes? It seems that you only increment the version if you add/remove data members, reorder them, or whatever. I don't really see a practical downside to having the library automatically puke if you are using old code to read a newer version of a class.
I don't expect the old version to read it successfully. The 'puke' as you put it at the moment is an access violation. Which basically may have left the process in an unstable state. I want it to 'puke' but with an exception that can be caught and handled gracefully. Not an access violation which basically means its anyones guess as to whether the software can run successfully. Read my original post on the matter again.
I understood your original post and by "puke" I obviously meant throw an exception --- what else did you expect? A silent exit? Core dump? Bill
# rael@zopyra.com / 2006-06-16 07:05:56 -0500:
On Friday, June 16, 2006 at 08:45:27 (+0100) Russell Hind writes:
Bill Lear wrote:
Versioning is per-class, and so why would you increment the version if you did not introduce forward-incompatible changes? It seems that you only increment the version if you add/remove data members, reorder them, or whatever. I don't really see a practical downside to having the library automatically puke if you are using old code to read a newer version of a class.
I don't expect the old version to read it successfully. The 'puke' as you put it at the moment is an access violation. Which basically may have left the process in an unstable state. I want it to 'puke' but with an exception that can be caught and handled gracefully. Not an access violation which basically means its anyones guess as to whether the software can run successfully. Read my original post on the matter again.
I understood your original post and by "puke" I obviously meant throw an exception --- what else did you expect? A silent exit? Core dump?
As far as I understand it, "access violation" is a segmentation fault, so yes, it is core dumping for him. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991
Roman Neuhauser wrote:
I understood your original post and by "puke" I obviously meant throw an exception --- what else did you expect? A silent exit? Core dump?
As far as I understand it, "access violation" is a segmentation fault, so yes, it is core dumping for him.
Yes, av's are seg faults, gpf's, core dumps or whatever else you want to term them. Sorry if that was misleading. It definitely wasn't throwing an exception which is what I wanted and why I asked about getting at the version so I could throw an exception myself to prevent the core dump. Cheers Russell
participants (4)
-
Bill Lear -
Roman Neuhauser -
Russell Hind -
Tarjei Knapstad