| Re: [henshin-dev] Technical details for Henshin model migration |
We should stick to one or the other strategie, i.e., automatically vs. manually triggered conversion! Moreover, we won't roll-out two editor for two henshin.ecore version. The standard editor for old henshin-file will be the standard sample reflective editor with all its drawbacks. regards Am 02.11.2011 12:06, schrieb Riegerf@xxxxxxxxxxxxxxxxxxxxxxx: > Quoting Stefan Jurack <henshin.stj@xxxxxxxxx>: >> 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. > > Since we don't seem to support executing old henshin files, every > henshin file needs to be converted to the new format. I think the > automatic conversion approach is sensible. However, some aspects to > consider: > 1) Automatic conversion at program runtime will impact performance. > Ideally, we should allow this for compatibility, but warn the user of > the negative impacts on performance etc. This could be done via the > IDE by creating warnings for "old" files. Where else will we brake > compatibility? Maybe "old" programs using henshin will not run anyway > and need to be refactored. If that is the case, automatic conversion > could be replaced by manually triggered conversion anyway, as it > offers no advantage and would lead to additional code in various > places, possibly making it harder to maintain. > 2) Typical users likely aren't concerned about the intricacies of our > releases, so they would expect to work on some henshin files, download > the new henshin version, and then continue working on their files. An > automatic conversion will inevitably fail if the henshin file is not > "correct." Since we don't (and shouldn't!) force correctness before > saving, it is not only possible--but should be expected--for henshin > files to be un-convertible before being fixed. The user should > therefore have the opportunity to fix the henshin file if the > conversion fails and then trigger a new conversion. Since the user > shouldn't be confronted with the henshin model, we should at least > keep the tree-editor to edit the old version of henshin files. > The double-click action for old henshin files should thus be: (i) > Attempt automatic conversion (ii) If conversion is successful, open in > "2011/2012" editor, done.; (iii) If conversion fails, popup a warning > stating the file needs to be fixed before it will run again, open in > "2010" editor. > Old henshin files should display a new menu entry to trigger the > conversion. The conversion could/should (?) create a backup of the old > henshin file as filename.henshin.bak > > > Felix > >> 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 >> >> >> > > > > _______________________________________________ > henshin-dev mailing list > henshin-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/henshin-dev
Attachment:
signature.asc
Description: OpenPGP digital signature