[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [henshin-dev] Should we introduce a new model version after renaming and restructuring model elements?
|
Felix,
the nsURI of the current Ecore model is
http://www.eclipse.org/emf/2002/Ecore. I highly doubt that they didn't
introduce any incompatible changes for 10 years.
Besides, I tried to explain already that the operations that a normal
user would do, that is loading, modifying and saving a Henshin model
work as before and without any need for migrating models. I am very
certain that none of our users is doing anything like in the code for
the migration tool.
Your approach does by now means guarantee that users don't get
unexpected results. Migrating model versions by chaining meta
transformations is tricky and error prone. Besides, if you really want
to make it correct, you would also have to deal with migrating HO
transformations defined over Henshin itself.
Cheers,
Christian
On 09/20/2012 04:57 PM, Riegerf@xxxxxxxxxxxxxxxxxxxxxxx wrote:
I'd like to discuss this on a more general level. My main point is
that we do not know in what way our users might use Henshin, so we
should not make changes that can break things.
Quoting Christian Krause <henshin.ck@xxxxxxxxx>:
Thus, I don't want to introduce a new version number.
But changing the model and not introducing a new version number is not
what I'd call good design. The best approach might be to introduce a
new version number after *any* alteration of the model, but this will
of course get excessive and tedious. A good compromise is to keep the
version number if you only add to the model, thus not breaking any
form of compatibility. However, if the model is changed in a way that
could potentially break compatibility, e.g. by renaming, new version
numbers should always be introduced.
We should figure out a way to trigger migrations in a clever and
generic way, so that old models can still be used transparently and
effortlessly. One way to approach this could be to use
meta-transformations that transform instances of one version of the
model into instances of the next version.
We only need to figure out once how to integrate this into our tools
and then we can use a stack of transformations to migrate a model of
any version to a model of the current version. I would consider this,
in the long term, to be a much more elegant solution to the problem
that we have to change the model from time to time.
It should be fairly simple to fix the existing migration code.
But is it also fairly simple to fix all the other code our users have
written? If I can write code that will fail with the new version, then
our users might also run into these problems--and as the model version
did not change, this will be very confusing and not obvious at all.
But since I'm making a general point here, I don't want to attach it
to some piece of code; it's a general question of how we should
approach model changes.
Felix
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
