[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [henshin-dev] Technical details for Henshin model migration
|
Hello everyone,
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
