views:

56

answers:

2

I am doing some significant refactoring and feature-adding on a project, and have just broken backwards compatibility with my data. I did it by creating a bunch of subclasses from the class that I used to house my data in, and loading in old serialized objects no longer works..

What kind of pre-engineering or strategies do you employ to avoid these types of situations? Should I forget about serialization completely? It seems particularly prone to these sorts of problems.

+1  A: 

I use XML. One of the little talked about aspects of XML is that it can be extended without breaking backward compatibility.

In other words...

<root>
  <something one="1" two="2"/>
</root>

...from revision A, has no problem being backwardly compatible with...

<root>
  <something one="1" two="2" three="3"/>
  <somethingElse five="5"/>
</root>

...from revision B.

dacracot
Although if you're going to do this, go all-out. Require validation, and use lots of decorators and noise so that interops will use a full XML system. Real-world systems like IM-XML require a specific order, and MRIS's XML feed is nothing more than a CSV-container.
geocar
Agreed. Use at least a DTD if not a schema.
dacracot
A: 

Aside from generally using a serialization mechanism that's at least somewhat tolerant of change, as dacracot describes, I try to set it up so that I can do some per-class tuning of the deserialization process. It's ugly to have conversion code for old data formats hanging around, but not as ugly as losing everything you have serialized.

chaos