| Re: [henshin-dev] Technical details for Henshin model migration |
Hi, the migration algorithm is to be implemented by Felix. From a technical point of view, the solution of shipping the "old" ecore file too, register it dynamically ....etc. sounds very good. However, I am not conviced, that the migration should take place automatically. I rather prefer a solution where the user is explicitely required to trigger the migration, e.g., in form of a context menu or when opening some of our editors. Afterwards, the new AND the "old" henshin files should exist to prevent data loss. regards, Stefan Am 02.11.2011 10:53, schrieb Christian Krause: > Hi everybody, > > version 0.9.0 will introduce changes in the Henshin model which will > break back-forward compatibility. Currently, we have two problematic > changes: > > * attribute NestedCondition.negated will be removed > * class AmalgamationUnit will be removed > > Therefore we need to come up with a user-friendly solution for > migrating 0.8.0 models to 0.9.0 models. > > To distinguish between the two versions we will change the namespace URI: > > * version 0.8.0: http://www.eclipse.org/emf/2010/henshin > * version 0.9.0: http://www.eclipse.org/emf/2011/henshin (or 2012) > > The question is how we migrate the existing 2010-models. Here is one > idea which could work: > > We change the namespace URI of the generated code to 2011/12. We keep > an old version of the model file and name it, say, henshin-2010.ecore. > We register the old model dynamically (no generated code). > > Now for the migration: We could transparently translate old models > when they are being loaded. For this, we change the resource > implementation (HenshinResource) such that whenever an old model is > loaded (the dynamic classes), it is automatically replaced by the new > version of the model. We would have to translate every dynamic class > by its corresponding generated class (the new version). > > To incorporate the changes, we would do the following: > > * If we find a 2010-version of NestedCondition which has the > attributed "negated" set to true, we wrap the generated instance in a > "Not". > > * If we find an AmalgamationUnit we do not create a corresponding new > element for it. Instead, we add the multi-rules and multi-mappings > directly to the generated version of the kernel rule. > > The approach has pros and cons: > > pro: easy to implement; users will not be bothered with migrating > their model; in, say, 95% of the cases no problem should occur; the > old version of the model will only be overridden on disk when the user > saves the model again > > con: the user might be surprised when the AmalgamationUnits suddenly > disappear. there can be cases where the automatic migration can fail. > but this is also true for other solutions. > > Please comment. > > Ciao, > Christian > > > _______________________________________________ > henshin-dev mailing list > henshin-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/henshin-dev
Attachment:
signature.asc
Description: OpenPGP digital signature