Serialising objects which change alot
-
I'm developing an object hierarchy which is beginning to stabilize now, but still things pop-up where I need to add a property to an object. This buggers up my serialized data, as after I add the property, run the app and deserialize, the member count doesn't match. Any suggestions on how to cope with this. I could do exports to comma sep to work around, but what do you do when you throw out a production system to the world. Writing data conversion stuff is a right PITA. Well, I await your expert input. Thanks Nursey
-
I'm developing an object hierarchy which is beginning to stabilize now, but still things pop-up where I need to add a property to an object. This buggers up my serialized data, as after I add the property, run the app and deserialize, the member count doesn't match. Any suggestions on how to cope with this. I could do exports to comma sep to work around, but what do you do when you throw out a production system to the world. Writing data conversion stuff is a right PITA. Well, I await your expert input. Thanks Nursey
Design your system first. If done properly the only changes you need to make will be minor. --Colin Mackay--
-
Design your system first. If done properly the only changes you need to make will be minor. --Colin Mackay--
-
Not the answer, "...commandment 11...and lo, users shall never change their minds..." mmmmm 8-) So how do you cope when things changes? Nursey
Yes, users will always change their minds so change is going to happen, but what I meant was that since the object heirarchy was in flux it should still be in the design phase. As it is now beginning to stabalise it can be moved to development phase. Changing it will still take some grunt work as you know already, but if it was changing so much before now I wonder why you were writing the code for it. --Colin Mackay--
-
Yes, users will always change their minds so change is going to happen, but what I meant was that since the object heirarchy was in flux it should still be in the design phase. As it is now beginning to stabalise it can be moved to development phase. Changing it will still take some grunt work as you know already, but if it was changing so much before now I wonder why you were writing the code for it. --Colin Mackay--
I think you have made assumptions about what this project is, its size and budget etc. I want to focus on how people cope with protecting their data using .NET serialization here. Let's just pretend it's a bedroom application, where we all cut code without UML, patterns and our refactoring handbook at the ready. If you serialize data with comma sep as your chosen data format, its a trivial matter to deserialize a different number of members to that which was serialized. My only interest here is in trying to abide by .NET's serialization techniques, purely for learning purposes. If .NET is going to throw an exception every time I add another property to my objects, and if .NET offers no alternative, then I need to reconsider my data storage techniques. Any talk of design and the like is off topic, and I've been there and done it all before, so I need to stick to what I don't know about, please. Nursey
-
I think you have made assumptions about what this project is, its size and budget etc. I want to focus on how people cope with protecting their data using .NET serialization here. Let's just pretend it's a bedroom application, where we all cut code without UML, patterns and our refactoring handbook at the ready. If you serialize data with comma sep as your chosen data format, its a trivial matter to deserialize a different number of members to that which was serialized. My only interest here is in trying to abide by .NET's serialization techniques, purely for learning purposes. If .NET is going to throw an exception every time I add another property to my objects, and if .NET offers no alternative, then I need to reconsider my data storage techniques. Any talk of design and the like is off topic, and I've been there and done it all before, so I need to stick to what I don't know about, please. Nursey
I hate to say it but I think this is something that is going to be bad for you. Just think of what it is like way back when they created Microsoft Word 1.0. You saved (serialize) something into a .doc format and saved it. Then after several years they significantly changed the doc format so that the new type is not backwards compatible. This is why they make document converters and why programs allow you to import data from older versions. The only thing I can think of would be to add a version number to your class that will get serialized out then when you read it in you can change the deserialize method of the class to check for the version and handle any known conversions as needed. I can see this as getting a but messy though if you are going through many lifecycles. Depending on what you are trying to do, if the formats are going to change a lot maybe you want to store your stuff in a database. This is simpler to add columns to and then as long as you don’t change the format of the existing data too much adding new things is not that hard. It is a catch 22 though. Using regular serialization is simpler because you have less to do, but in your case I think it is ending up being more of a pain than just putting a bit more work into making your storage mechanism a but more robust and less brittle.
Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall." George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things." Jörgen Sigvardsson wrote: If the physicists find a universal theory describing the laws of universe, I'm sure the asshole constant will be an integral part of that theory.
-
I hate to say it but I think this is something that is going to be bad for you. Just think of what it is like way back when they created Microsoft Word 1.0. You saved (serialize) something into a .doc format and saved it. Then after several years they significantly changed the doc format so that the new type is not backwards compatible. This is why they make document converters and why programs allow you to import data from older versions. The only thing I can think of would be to add a version number to your class that will get serialized out then when you read it in you can change the deserialize method of the class to check for the version and handle any known conversions as needed. I can see this as getting a but messy though if you are going through many lifecycles. Depending on what you are trying to do, if the formats are going to change a lot maybe you want to store your stuff in a database. This is simpler to add columns to and then as long as you don’t change the format of the existing data too much adding new things is not that hard. It is a catch 22 though. Using regular serialization is simpler because you have less to do, but in your case I think it is ending up being more of a pain than just putting a bit more work into making your storage mechanism a but more robust and less brittle.
Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall." George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things." Jörgen Sigvardsson wrote: If the physicists find a universal theory describing the laws of universe, I'm sure the asshole constant will be an integral part of that theory.
Ray, Replies like yours are the reason I love this web site, well thought out, constructive and strictly in the vein of the problem. Thanks you. I think I have a partially thought out solution... If I serialize class A and want to add members to it then I should derive A using class B and add the members there. I can call A.Serialize from B.SerializeOldVersion, get me? Then I can B.Serialize and B.Deserialize and all my new members will be handled correcly. OK, its partially thought out because if there are relating objects then those relationships could mudy the water somewhat. But in theory, this meets the "don't change your interfaces" school of thought. I think deriving would certainly be the way through to data conversion though, then effectively you can roll all the stuff up into one class again. My ambitious thoughts are in this area though. As I am using SOAP format for serialization as oppose to binary format, at least for the time being (there's nothing quite like being able to see your megabytes of data in text format hehehe) well...to cut a long one short, there ought to be a structured way of massaging the data. i.e. you could write an XML parser, which a very good friend of ours on here has done recently, and insert the new fields where neccessary...then hey presto. I think there is definite potential in this approach. Again, your additional thoughts are very welcome. Many thanks. Nursey