Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 5 down vote favorite
1

I have a ASP.NET web based application that allows the end user to export data to a flat file format. (essentially taking a point-in-time backup of their work)

At a later date they can re-upload (import) that data back into the web application.

The actual format of the backup is pretty trivial. An object graph is serialized using the WCF DataContractSerializer to xml, and then the resultant xml document is compressed. Importing, unzips it and deserializes the data.

There's one small problem I see with this approach. versioning... as time moves on and the data structures change (properties / child-collections are added/removed or renamed) then previously exported versions of a users data will no longer map to the object graph in the application.

Are there any specifici patterns or practices that address this issue? or any other reading material you could recommend.

share|improve this question
Maybe have a data format version number in the file? Read that first, and use that to determine how to import the rest of the data. – FrustratedWithFormsDesigner Apr 17 '12 at 13:43
3  
Data Contract Versioning and related SO question. – Oded♦ Apr 17 '12 at 13:53
@Oded: Maybe you should expand that into an answer? – FrustratedWithFormsDesigner Apr 17 '12 at 14:57
@FrustratedWithFormsDesigner - I don't really have enough for a proper answer. This is not an easy one... – Oded♦ Apr 17 '12 at 15:05

2 Answers

up vote 1 down vote

We have been using .NET Xml Serialization of pretty big graph of .NET objects for several years. We opted to take a very simple approach: keep the objects backward compatible at the code level. We generally only add new properties, and in the one case where we modified the datatype of a property, we created a new property with the modified datatype, and initialized it from the old data when user upgraded.

I think the one best practice we instituted, was that any new properties were always added as a full fledged property, and not just a class member variable. This enabled us to ensure that the code always initialized the new property to a helpful default value (instead of the blank/null value which it initializes to during deserialization.)

This has covered us for upgrades to the application over 5 years, with no bugs caused by deserializing old versions of the objects into newer version of the application. (once we adopted the approach above).

share|improve this answer
up vote 0 down vote

Have you considered adding a version to your export and then doing a version comparison during import?

If versions don't match, you can either fail import or warn the user that import is likely to fail, I don't see any other reasonable way of solving this.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.