no data migration in AW5

[William la Forge]

In AgileWiki4, data migration was broken--it could not handle changes to the set of operations. That is no longer an issue in AW5, as the operation set is not persistent but is based entirely on the rolon type. The question then is, how do we migrate from one architecture to another when we are keeping old versions of rolons?

In AW4, plugins were used to define architecture, which consists largely of singleton rolons (where there is only one instance for a given rolon type). We will need to do something similar in AW5, but we can't simply use updated plugins and migrate the data to the new architecture. Rather, architecture will need to be created when a plugin is installed and updated when a plugin is upgraded. And when accessing an old version of a rolon, the updated operations will need to work with the old data.

The first question then is, how can we tell which version of the plugin might have been used for a given version of a rolon. We can easily track when each plugin was installed on a single system, but what about information sharing across systems? Plugins will be upgraded at different times on different systems. Our fall back here is "less is more." When a plugin needs to distinguish new content from old, it needs to tag the new content.

As for installing or upgrading to a new plugin, this can also be left to the plugins themselves. When starting up the AW5 core, we should first start the kernel and then pass control to each of the plugins. A plugin then can execute a startup transaction which can check to see if it is a new or updated plugin and perform the appropriate database updates. What we have then is plug & play plugins, where the only requirement is to restart AW5. Of course, the plugins then must handle the problem of an old plugin working with data from an upgraded plugin--this will happen when data is shared across systems. (Fortunately, shared data doesn't get updated as it is publish and subscribe in nature. This makes things a lot easier.)

And we no longer need data migration.

Bill