|
|
|
| Re: ecore2ecore: can i control the mapping? [message #492656 is a reply to message #492650] |
Wed, 21 October 2009 09:32   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050304020701000104090204
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Peter,
Comments below.
peter barry wrote:
> hi ed, thanks for your reply
>
> your comments
>
> "Of course you'd be best off to make only binary compatible changes from
> release to release so that no migration is involved. That's what we've
> done with Ecore; we even added generics without breaking the older
> serialization format (and ensured that when you don't use generics, we
> still produce the older serialization format)."
>
> correct me if i am wrong but is this what you mean -
> if a model needs to change then keep legacy data in the new version of
> the model so that older model data can still be serialised?
Yes.
> does the nsUri of the new model then stay the same as the old model so
> that there are no difficulties in finding the correct package for the
> old model?
Yes, that's what we've done.
>
> when you mention what you've done for ecore, do you mean that when you
> released the new version of ecore (emf?) you handled the model changes
> such that models using an older version of emf would still work with
> the new version of emf?
Exactly. We added a lot of stuff in EMF 2.3 to support Java-style
generics without breaking the serialization. E.g., all the containment
references eGenericAbc where added to augment eAbc references. Reading
the old references automatically populates the newer containment
references and the serialization relies on unsettable feature behavior
to insure that the older features are serialized when no actual use if
made of generics. So generally the idea is don't ever remove anything
from your model. Only deprecate them and ensure that setting such
feature's values automatically migrates the data. You might make such a
feature transient so it's never saved again.
>
> can you explain a bit more on how you managed this, or even point me
> to the relevant code in the emf code base?
Have a look at the getters and setters in ETypedElementImpl for eType
and eGenericType.
This option is useful too:
/**
* This options allows you to record unknown features during
deserialization/loading.
* The default is <code>Boolean.FALSE</code> unless set to
<code>Boolean.TRUE</code> explicitly.
* The unknown features and their values can be accessed via
getEObjectToExtensionMap().
* @see #getEObjectToExtensionMap()
*/
String OPTION_RECORD_UNKNOWN_FEATURE = "RECORD_UNKNOWN_FEATURE";
It can even allow your v1 software to read v3 versions of the model and
have it write back out the v3 data on save...
>
> thanks again!
> -peter
--------------050304020701000104090204
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter,<br>
<br>
Comments below.<br>
<br>
peter barry wrote:
<blockquote cite="mid:hbmj70$cmc$1@build.eclipse.org" type="cite">hi
ed, thanks for your reply
<br>
<br>
your comments
<br>
<br>
"Of course you'd be best off to make only binary compatible changes
from
<br>
release to release so that no migration is involved. That's what we've
<br>
done with Ecore; we even added generics without breaking the older
<br>
serialization format (and ensured that when you don't use generics, we
<br>
still produce the older serialization format)."
<br>
<br>
correct me if i am wrong but is this what you mean - <br>
if a model needs to change then keep legacy data in the new version of
the model so that older model data can still be serialised? </blockquote>
Yes.<br>
<blockquote cite="mid:hbmj70$cmc$1@build.eclipse.org" type="cite">does
the nsUri of the new model then stay the same as the old model so that
there are no difficulties in finding the correct package for the old
model?
<br>
</blockquote>
Yes, that's what we've done. <br>
<blockquote cite="mid:hbmj70$cmc$1@build.eclipse.org" type="cite"><br>
when you mention what you've done for ecore, do you mean that when you
released the new version of ecore (emf?) you handled the model changes
such that models using an older version of emf would still work with
the new version of emf?
<br>
</blockquote>
Exactly. We added a lot of stuff in EMF 2.3 to support Java-style
generics without breaking the serialization. E.g., all the containment
references eGenericAbc where added to augment eAbc references. Reading
the old references automatically populates the newer containment
references and the serialization relies on unsettable feature behavior
to insure that the older features are serialized when no actual use if
made of generics. So generally the idea is don't ever remove anything
from your model. Only deprecate them and ensure that setting such
feature's values automatically migrates the data. You might make such
a feature transient so it's never saved again. <br>
<blockquote cite="mid:hbmj70$cmc$1@build.eclipse.org" type="cite"><br>
can you explain a bit more on how you managed this, or even point me to
the relevant code in the emf code base?
<br>
</blockquote>
Have a look at the getters and setters in ETypedElementImpl for eType
and eGenericType.<br>
<br>
This option is useful too:<br>
<blockquote> /**<br>
* This options allows you to record unknown features during
deserialization/loading.<br>
* The default is <code>Boolean.FALSE</code> unless set
to <code>Boolean.TRUE</code> explicitly. <br>
* The unknown features and their values can be accessed via
getEObjectToExtensionMap().<br>
* @see #getEObjectToExtensionMap() <br>
*/<br>
String OPTION_RECORD_UNKNOWN_FEATURE = "RECORD_UNKNOWN_FEATURE";<br>
</blockquote>
It can even allow your v1 software to read v3 versions of the model and
have it write back out the v3 data on save...<br>
<blockquote cite="mid:hbmj70$cmc$1@build.eclipse.org" type="cite"><br>
thanks again!
<br>
-peter
<br>
</blockquote>
</body>
</html>
--------------050304020701000104090204--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: ecore2ecore: can i control the mapping? [message #492688 is a reply to message #492686] |
Wed, 21 October 2009 12:08 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Peter,
Comments below.
peter barry wrote:
> hi ed,
>
> what was the main reason for you to decide on this approach?
It seemed by far the least disruptive to the clients and to the other
tools downstream from Ecore.
> when you look at the literature on migrating ecores it generally
> mentions that you should bear in mind the future migration of the
> model, therefore naming the nsURI appropriately.
We did include a year in the nsUR so we could change it in the future.
>
> for you was it the need to make your customers move to 2.3 etc as
> painless as possible or were there other reasons?
Yes people complain a lot when there's a little bit of pain. I
considered a major accomplishment that I was able to add generics to
Ecore without anyone at IBM complaining about being adversely impacted,
i.e., needing to lift a finger...
>
> thanks for your help
> -peter
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03687 seconds
] 
Search
Help
Register
Login
Home
