|
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. |
|
> 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:
|
