Some time ago I did some wishful thinking in regard to Data Version Control. I was looking for a versioning scheme for data, the same way SVN does versioning for code. The problem is that of a word processor, for example, should really be able to open documents of a newer version, as well as documents of an older version than the version of the word processor itself.

My cousin Bjinse now showed me the very elegant way Ruby on Rails solves this problem (check the third demo "Evolving your database schema without a sweat"). In this solution, a data source (an SQL database in this case) always contains a version number. Furthermore, for every "version migration" (i.e. from version 2 to 3), there is a piece of migration code that performs the migration of the data. And also, there is the fact that the migration doesn't just exist of a series of SQL statements, it can also contain any arbitrary code. Which makes the migration extremely flexible.

Another good thing is that for every incremental migration, there is also a piece of decremental code. This code reverts the data to the previous version (i.e. from version 3 to 2). In order to import data from a newer version into your old database system, simply revert this data a few steps and do the import. Very beautiful.

Now back to our word processor. Suppose you own a version 1995 word processor and need to feed it a version 2006 document. Where is the migration code to be stored? It cannot be stored in the old application, since it has no knowledge of future versions. It can be provided by the application developer. The document may tell the application which version it has. The application may then fetch the migration code from the internet and revert the data to the older version. Obviously there will be a loss of functionality in the document, but that may very well be acceptable.

This versioning scheme is not even necessarily sequential (having version numbers 1, 2, 3, ...), it can also be used in somewhat more complex forms of versioning (after version 2 the scheme may fork into versions 3A and 3B that are incompatible; a version 3B document can first be reverted to a version 2 document and then migrated to version 3A).

Interesting!