Home » Modeling » EMF » Schema evolution: reference to attribute
| Schema evolution: reference to attribute [message #530466] |
Thu, 29 April 2010 17:25  |
 Carsten Reckord
Messages: 139
Registered: July 2009 |
Senior Member |
|
|
Hi,
I am trying to get a Resource set up to read and write an old version of my model using its current implementation and a customized
XMIResource. Between the two model versions, I changed a Class to a DataType and some containment references typed with that class to
attributes. The old model looked like this (excerpt):
graph <<Package, nsUri="http:///graph/0.1">>
Node <<Class>>
color:Color <<containment reference>>
Color <<Class>>
red:EInt <<attribute>>
green:EInt <<attribute>>
blue:EInt <<attribute>>
The new one is
graph <<Package, nsUri="http:///graph/0.2">>
Node <<Class>>
color:Color <<attribute>>
Color <<DataType, instanceClass="org.example.graph.ColorObject">>
ColorObject <<Class>>
red:EInt <<attribute>>
green:EInt <<attribute>>
blue:EInt <<attribute>>
(Note that the Color DataType uses the ColorObject as its instanceClass/implementation)
Using the EMF Data Migration recipe (http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration), I managed to cobble up a solution that
reads the old data. However, I had to (re-)add a reference
colorObject:ColorObject <<reference, derived, transient, volatile>>
to the Node class onto which I mapped the old reference, and delegating to the color attribute accessors in the code. (I also had to add a
mapping for the "new" color attribute to the XMLMap to declare its xmlRepresentation as ATTRIBUTE, otherwise it was found as a valid mapping
for the old color element)
Question 1: Can this be achieved without the additional reference?
Question 2: How do I get my Resource set up to write XMI that conforms to my old model?
Since the 'colorObject' feature is transient, it will be discarded by the XMLSave apparently without a chance to override this with the
XMLHelper or ExtendedMetaData. And I don't see a way to save the 'color' attribute as a nested, structured element (I can get it as an
element with text content, i.e. <color>0,0,0</color>, but I need the old <color red="0 green="0" blue="0"/>)
Best regards,
Carsten
|
|
|
| Re: Schema evolution: reference to attribute [message #530619 is a reply to message #530466] |
Fri, 30 April 2010 10:19  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Carsten,
Comments below.
Carsten Reckord wrote:
> Hi,
>
> I am trying to get a Resource set up to read and write an old version
> of my model using its current implementation and a customized
> XMIResource. Between the two model versions, I changed a Class to a
> DataType and some containment references typed with that class to
> attributes. The old model looked like this (excerpt):
>
> graph <<Package, nsUri="http:///graph/0.1">>
> Node <<Class>>
> color:Color <<containment reference>>
> Color <<Class>>
> red:EInt <<attribute>>
> green:EInt <<attribute>>
> blue:EInt <<attribute>>
>
> The new one is
>
> graph <<Package, nsUri="http:///graph/0.2">>
> Node <<Class>>
> color:Color <<attribute>>
> Color <<DataType, instanceClass="org.example.graph.ColorObject">>
> ColorObject <<Class>>
> red:EInt <<attribute>>
> green:EInt <<attribute>>
> blue:EInt <<attribute>>
>
> (Note that the Color DataType uses the ColorObject as its
> instanceClass/implementation)
>
> Using the EMF Data Migration recipe
> (http://wiki.eclipse.org/EMF/Recipes#Recipe:_Data_Migration), I
> managed to cobble up a solution that reads the old data. However, I
> had to (re-)add a reference
>
> colorObject:ColorObject <<reference, derived, transient, volatile>>
>
> to the Node class onto which I mapped the old reference, and
> delegating to the color attribute accessors in the code. (I also had
> to add a mapping for the "new" color attribute to the XMLMap to
> declare its xmlRepresentation as ATTRIBUTE, otherwise it was found as
> a valid mapping for the old color element)
>
> Question 1: Can this be achieved without the additional reference?
I suppose another approach to try is to use
OPTION_RECORD_UNKNOWN_FEATURES and post process the recorded XML data
for the containment reference's element to transform it to the new
representation.
>
> Question 2: How do I get my Resource set up to write XMI that conforms
> to my old model?
That's easier said than done without a model model that specifies this.
> Since the 'colorObject' feature is transient, it will be discarded by
> the XMLSave apparently without a chance to override this with the
> XMLHelper or ExtendedMetaData. And I don't see a way to save the
> 'color' attribute as a nested, structured element (I can get it as an
> element with text content, i.e. <color>0,0,0</color>, but I need the
> old <color red="0 green="0" blue="0"/>)
If you keep the old containment reference you're trying to get rid of
you could specialize XMLSaveImpl.Lookup.featureKind to treat it as if it
weren't transient and to treat the attribute as transient instead.
>
>
> Best regards,
> Carsten
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 27 04:57:38 GMT 2024
Powered by FUDForum. Page generated in 0.02945 seconds |
] 
Search
Help
Register
Login
Home
