Desktopcouch needs a simple data migration mechanism

[Eric Casteleijn]

When changes are made to the way data is stored in couchdb by desktopcouch or any of the applications that use it, we need to provide a way to upgrade data where needed. We'd prefer this to be a simple mechanism that will have minimal impact on overall performance, and will be relatively easy to use by application developers.

[Eric Casteleijn (thisfred)]

The design Vincenzo and I came up with so far:

For each data migration that needs to happen, create a view that checks for the presence of the old feature, or the absence of the new feature on each document, and register a migration script or class in the code to deal with the documents that the view returns. Then on couchdb startup, run the migration views and fix any resulting documents.

We will need a way to register the views/migration scripts agains specific databases, or all databases. (Views should be smart enough that they ignore anything that is not a desktopcouch records, so that we don't mess with any non-desktopcouch data in the case we're talking to all dbs.)