I've the feeling only one deployed version is supported : Am I correct? Our application is deployed on many servers, so different versions are deployed at any given time and we need migration to latest version to be as smooth as possible.

Let's say I want to allow upgrade to latest version (1.0.1.123). If oldversion is smaller than 1.0.1.0, I have some migration code to execute. If oldversion is 1.0.1.X, there is nothing to do.

How should I implement my Upgrader class so that I can migrate from 1.0.0.23 and 1.0.1.42 to the latest version 1.0.1.123 ? In other words, is there a pattern to change migration code depending on the old version?

Regards, Julien


Updated at 15.06.2010 14:23:00

I understand this would be the scenario for a complex schema migration scenario. It is a complex scenario but required in this case.

However I must be able to do the same in a very simple scenario: I will give an example.

  • Version 1

    [HierarchyRoot] public class MyEntity { [Field, Key] public long Id { get; private set;}

    [Field] public string Text { get; set;} }

  • Version 2 Add "Viewer" field with a non automatic default value

    [HierarchyRoot] public class MyEntity { [Field, Key] public long Id { get; private set;}

    [Field] public string Text { get; set;}

    [Field] public string Viewer { get; set;}

    public MyEntity() { Viewer = "Default Viewer"; } }

  • Version 3 Rename "Text" to "Name" field

    [HierarchyRoot] public class MyEntity { [Field, Key] public long Id { get; private set;}

    [Field] public string Name { get; set;}

    [Field] public string Viewer { get; set;}

    public MyEntity() { Viewer = "Default Viewer"; } }

I should be able to write an UpgradeHandler that can migrate from v1 to v3 and v2 to v3.

How can I do this?

I could write an UpgradeHandler that allow upgrade from any previous version, and performs conditional upgrade depending on OldVersion. However the old version does not seem to be available in UpgradeContext object of UpgradeHandler class. Is this possible to use the old version provided in CanUpgradeFrom method? Is there a 'clean' way to get the old version?

Regards,

This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Jun 15 '10 at 08:52

olorin's gravatar image

olorin
358878792


One Answer:

To simplify everything, let's consider there is v1, v2 and v3. Moreover,

  • v2 knows (= has corresp. upgrade handlers) how to migrate from v1 to v2

  • v3 knows (= has corresp. upgrade handlers) how to migrate from v2 to v3

We must be able to migrate from v1 to v3 as well. It's easy to achieve this, if v3 is shipped with a subset of v2 allowing to run its Domain to perform upgrade. Or, if there is v4, it should contain both v2 and v3 assemblies somewhere to perform incremental upgrade.

So I would:

  • Create a folder called "Migration" with "vA.B.C.D" subfolders for assemblies of these versions

  • Implement incremental upgrade tool (separate application) that would e.g. try to sequentially start a Domain for each of "vA.B.C.D" in new AppDomain. It's a good idea to captured its log and console output as well.

  • Modified a routine building Domain in my application to allow it to fallback to an incremental upgrade path: if it can't build a Domain because it can't upgrade to the current version, it must launch incremental upgrade tool and try this once more.

That's it.


The problem with such upgrades is actually related to multple versions of mappings:

  • When your upgrade handlers migrate schema from A to B, we can (after precisely defined set of renames & copy operations described by upgrade hints) provide you a schema containing both old and new structures. So we can map entities to tables, allow custom upgrade steps to run and finally get rid of all old structures and types.

  • If you migrate from (A or B) to C, the same generally isn't possible, since schema before upgrade depends on version we upgrade from.

So if you really need this kind of upgrade, I recommend you to rely on regular SQL here. Upgrade pattern we use isn't designed for such multi-version upgrades.

answered Jun 15 '10 at 09:21

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×574

Asked: Jun 15 '10 at 08:52

Seen: 4,414 times

Last updated: Jun 15 '10 at 08:52

powered by OSQA