1

I am using XStream to persist Java objects to files. This works fine and so far I have had no problems.

However, in the course of development, the objects have changed. Some new properties have been added, some have been replaced by more flexible alternatives and some have become redundant.

My approach has been to add new properties as necessary but never to delete redundant ones. Properties which are replacements for older ones attempt to initialise themselves once using the old data.

In the long term I guess this might become a nightmare with objects becoming full of redundant data. But somehow I have to ensure that files saved using older formats can still be read. At the moment, XStream throws an exception if an XML node has no corresponding property.

I could imagine using version numbers and providing converters between versions but I think this could get quite tricky. Some kind of migration would need to be triggered when the version number changes and the change necessary could be over more than one version release.

What strategies have you used successfully to handle 'living' objects?

paul
  • 1,201
  • 9
  • 10
  • 1
    just noticed this very similar question: http://programmers.stackexchange.com/questions/142916/strategy-for-backwards-compatibility-of-persistent-storage?rq=1 – paul Feb 18 '15 at 12:01
  • 2
    Look into the XStream FAQ http://xstream.codehaus.org/faq.html , section 2, "How does XStream deal with newer versions of classes?" – Doc Brown Feb 18 '15 at 12:42

0 Answers0