Strategy for backwards compatibility of persistent storage

Posted by Baqueta on Programmers See other posts from Programmers or by Baqueta
Published on 2012-04-04T10:30:00Z Indexed on 2012/04/04 11:40 UTC
Read the original article Hit count: 284

In my experience, trying to ensure that new versions of an application retain compatibility with data storage from previous versions can often be a painful process.

What I currently do is to save a version number for each 'unit' of data (be it a file, database row/table, or whatever) and ensure that the version number gets updated each time the data changes in some way. I also create methods to convert from v1 to v2, v2 to v3, and so on. That way, if I'm at v7 and I encounter a v3 file, I can do v3->v4->v5->v6->v7.

So far this approach seems to be working out well, but I haven't had to make use of it extensively yet so there may be unforseen problems. I'm also concerned that if the objects I'm loading change significantly, I'll either have to keep around old versions of the classes or face updating all my conversion methods to handle the new class definition.

Is my approach sound? Are there other/better approaches I could be using? Are there any design patterns applicable to this problem?

© Programmers or respective owner

Related posts about language-agnostic

Related posts about persistence