Hallo Alex,

I've evaluated schema evolution during the weekend and i have some questions about that:

First of all: Is it completely implemented?

Concerning the Model: I've seen that you version the model with Namespaces. Something like: .Model.V1 .Model.V2 Different Versions of the Model (at least for the same Entities) must stay in the same Assembly due to the needs of UpgradeHandler?

Concerning RenameFieldHint: It is declared as public abstract class RenameFieldHint

is this correct? I would have expected: public sealed class RenameFieldHint How can i use it to rename a field (property) in my model?

I've seen the attribute: [Recycled, Obsolete]

As in your sample he transformation process requires a Meta Version (in your sample Version 2) which is able to store the new and the old representation. Is this the desired pattern? On complex updates i must always use the pattern: namespace Model.OldModel namespace MetaModel (containing old and new representation for the transformation ) namespace NewModel

Kind regards

Thomas

This thread was imported from our support forum. The original discussion may contain more detailed answer. Original topic by MSE-iT.

asked May 17 '09 at 19:32

Editor's gravatar image

Editor
46154156157


One Answer:

> First of all: Is it completely implemented?

No, it was a partial implementation. E.g. none of model level upgrade hints were working (although rename hint @ schema level was) and you could add new fields only to the end of the class.

> Different Versions of the Model (at least for the same Entities) must stay in the same Assembly due to the needs of UpgradeHandler?

No, surely not. There are actually should be different versions of the same assembly (you can rename it, but IUpgradeHandler.AssemblyName must stay the same), and each subsequent version may contain an upgrade handler describing how to upgrade it from the previous version.

The sample uses the same assembly, because this is simpler. Moreover, it shows how to provide custom type names (the ones that associated with TypeIds). Our intention was to show the upgrade using the most simple path from the point of code amount.

> I've seen the attribute: [Recycled, Obsolete]

The first one currently works, but not as it finally should: currently it ensures the type is available only till the upgrade stage (i.e. only in a set of events of upgrade handler). So if it is applied, it ensures you can extract the info from the instances of this type during the custom upgrade.

The second attribute is applied to inform the people that this type is actually not available.

P.S. The upcoming update (btw, it will be v4.0 final - I'll publish a large announcement on this weekend; currently we're planning to release it during the first week of June) will bring the upgrade working in full power. In particular:

  • Class, field rename & copy will be fully supported - now we're storing old model to handle this gracefully

  • Some more complex restructuring actions will also be supported (e.g. renaming of struct field)

  • [Recycled] will also imply movement of the type to "Recycled" namespace

  • Most of hints will automatically be created based on attributes.

answered May 22 '09 at 12:47

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:

×573

Asked: May 17 '09 at 19:32

Seen: 2,287 times

Last updated: May 17 '09 at 19:32

powered by OSQA