|
|
| Re: Aliasing model features [message #418184 is a reply to message #418050] |
Fri, 04 April 2008 13:23   |
 Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Eric,
>
> You can use an extended meta data annotation to specify the name as it
> should appear in the XML.
>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//String">
> <eAnnotations
> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
> <details key="name" value=*"title"*/>
> </eAnnotations>
> </eStructuralFeatures>
>
> This will make it save back in that form as well, so you might use the
> extended meta data option only for loading.
OK, this looks promising. Just in case someone else stumbles upon this
thread looking for a similar solution, the key is that you have to
specify load options to the Resource
(org.eclipse.emf.ecore.resource.Resource). The specific option Ed is
talking about is XMLResource.OPTION_EXTENDED_META_DATA and it has to be
an implementation of ExtendedMetaData.
Ed, in trying to get that to work, I came across something that seems
like either a bug or a glaring omission in documentation:
I had set my ExtendedMetaData into the load options but it was not
getting used. An hour later of stepping through the serialization code,
I found this line in XMLHelperImpl:
else if (laxFeatureProcessing && extendedMetaData != null)
(line 935 in the 2.3.2 version of org.eclipse.emf.ecore.xmi)
This is coming into play if the XML contains a feature name that can't
be found in the model (my scenario exactly). But it results in the
extendedMetaData being used to look up the unknown feature name ONLY if
the option XMLResource.OPTION_LAX_FEATURE_PROCESSING is also set to true.
Is that the intended behavior or a bug? If intended, it really needs to
be clearly documented - someone who is not as persistent as I and
willing to dive into the source code would never know from the current
documentation of either XMLResource.OPTION_LAX_FEATURE_PROCESSING or
XMLResource.OPTION_EXTENDED_META_DATA.
Eric
> Eric Rizzo wrote:
>> I'm facing a situation where I would like to change the name of an
>> EAttribute in my model but am not allowed to break existing model
>> instances. So I need the XML deserialization to be tolerant of the old
>> name and convert it to the new name for the in-memory model (and
>> subsequently use the new name when serializing back to XML).
>> Is this something that the extendedMetaData EAnnotation can help with?
>> Is there any other option other than writing my own serialization impl?
>>
>> TIA,
>> Eric
>
|
|
|
| Re: Aliasing model features [message #418186 is a reply to message #418184] |
Fri, 04 April 2008 14:08 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Eric,
Comments below.
Eric Rizzo wrote:
> Ed Merks wrote:
>> Eric,
>>
>> You can use an extended meta data annotation to specify the name as
>> it should appear in the XML.
>>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
>> lowerBound="1" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2003/XMLType#//String">
>> <eAnnotations
>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>> <details key="name" value=*"title"*/>
>> </eAnnotations>
>> </eStructuralFeatures>
>>
>> This will make it save back in that form as well, so you might use
>> the extended meta data option only for loading.
>
> OK, this looks promising. Just in case someone else stumbles upon this
> thread looking for a similar solution, the key is that you have to
> specify load options to the Resource
> (org.eclipse.emf.ecore.resource.Resource). The specific option Ed is
> talking about is XMLResource.OPTION_EXTENDED_META_DATA and it has to
> be an implementation of ExtendedMetaData.
>
> Ed, in trying to get that to work, I came across something that seems
> like either a bug or a glaring omission in documentation:
> I had set my ExtendedMetaData into the load options but it was not
> getting used. An hour later of stepping through the serialization
> code, I found this line in XMLHelperImpl:
>
> else if (laxFeatureProcessing && extendedMetaData != null)
Well, another approach would have been to specify <details key="kind"
value="attribute"/>. Generally extended meta data is used to make
things conform to an XML Schema serialization where you might well and
have element and and attribute with exactly the same name. So mostly
this is a documentation issue. What would be really useful would be to
create an EMF recipe for solving this problem that described all these
subtle things...
>
> (line 935 in the 2.3.2 version of org.eclipse.emf.ecore.xmi)
>
> This is coming into play if the XML contains a feature name that can't
> be found in the model (my scenario exactly). But it results in the
> extendedMetaData being used to look up the unknown feature name ONLY
> if the option XMLResource.OPTION_LAX_FEATURE_PROCESSING is also set to
> true.
> Is that the intended behavior or a bug? If intended, it really needs
> to be clearly documented - someone who is not as persistent as I and
> willing to dive into the source code would never know from the current
> documentation of either XMLResource.OPTION_LAX_FEATURE_PROCESSING or
> XMLResource.OPTION_EXTENDED_META_DATA.
It is intentionally working this way but the documentation is indeed
sadly deficient. At the very least there should be an @see and some
commentary to help in uninitiated. Feel free to open a bugzilla to
enhance the Javadoc... I'll ask Dave to look at the book's descriptions
of these options to make sure it's clear there...
>
> Eric
>
>
>
>> Eric Rizzo wrote:
>>> I'm facing a situation where I would like to change the name of an
>>> EAttribute in my model but am not allowed to break existing model
>>> instances. So I need the XML deserialization to be tolerant of the
>>> old name and convert it to the new name for the in-memory model (and
>>> subsequently use the new name when serializing back to XML).
>>> Is this something that the extendedMetaData EAnnotation can help with?
>>> Is there any other option other than writing my own serialization impl?
>>>
>>> TIA,
>>> Eric
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Aliasing model features [message #418199 is a reply to message #418186] |
Fri, 04 April 2008 18:54 |
Eric Rizzo
Messages: 3070
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Eric,
>
> Comments below.
>
> Eric Rizzo wrote:
>> Ed Merks wrote:
>>> Eric,
>>>
>>> You can use an extended meta data annotation to specify the name as
>>> it should appear in the XML.
>>>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
>>> lowerBound="1" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2003/XMLType#//String">
>>> <eAnnotations
>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>> <details key="name" value=*"title"*/>
>>> </eAnnotations>
>>> </eStructuralFeatures>
>>>
>>> This will make it save back in that form as well, so you might use
>>> the extended meta data option only for loading.
>>
>> OK, this looks promising. Just in case someone else stumbles upon this
>> thread looking for a similar solution, the key is that you have to
>> specify load options to the Resource
>> (org.eclipse.emf.ecore.resource.Resource). The specific option Ed is
>> talking about is XMLResource.OPTION_EXTENDED_META_DATA and it has to
>> be an implementation of ExtendedMetaData.
>>
>> Ed, in trying to get that to work, I came across something that seems
>> like either a bug or a glaring omission in documentation:
>> I had set my ExtendedMetaData into the load options but it was not
>> getting used. An hour later of stepping through the serialization
>> code, I found this line in XMLHelperImpl:
>>
>> else if (laxFeatureProcessing && extendedMetaData != null)
> Well, another approach would have been to specify <details key="kind"
> value="attribute"/>. Generally extended meta data is used to make
> things conform to an XML Schema serialization where you might well and
> have element and and attribute with exactly the same name.
I was unable to get it to work by using the annotation - I had to set an
ExtendedMetaData into the load options. I extend BasicExtendedMetaData
and make a call like this in its constructor:
setName(MyPackage.eINSTANCE.getMyType_newAttributeName(),
"oldAttributeName");
This being set as the OPTION_EXTENDED_META_DATA along with true set for
OPTION_LAX_FEATURE_PROCESSING seems to work (I can load XML that
contains "oldAttributeName" into the new model that uses
"newAttributeName").
I tried just an annotation like this:
<eStructuralFeatures xsi:type="ecore:EAttribute" name="newAttributeName"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2003/XMLType#//String">
<eAnnotations
source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="attribute"/>
<details key="name" value="oldAttributeName"/>
</eAnnotations>
</eStructuralFeatures>
And setting no load options at all. But that didn't work. It complains
that "Feature 'oldAttributeName" not found."
Furthermore, it appears that setting my ExtendedMetaData class into the
load options via code is sufficient without the annotation.
Sorry for being this so dense, but can you explain again the "best"
solution with more details, assuming I don't know anything about this
stuff. I don't want to go forward with a "solution" that I don't fully
understand, especially since I am telling the team that we can use this
for model migration going forward.
I promise to reciprocate by writing up a wiki recipe entry once I fell
comfortable that I know what I'm doing and why it works ;-)
Thanks,
Eric
>>
>> (line 935 in the 2.3.2 version of org.eclipse.emf.ecore.xmi)
>>
>> This is coming into play if the XML contains a feature name that can't
>> be found in the model (my scenario exactly). But it results in the
>> extendedMetaData being used to look up the unknown feature name ONLY
>> if the option XMLResource.OPTION_LAX_FEATURE_PROCESSING is also set to
>> true.
>> Is that the intended behavior or a bug? If intended, it really needs
>> to be clearly documented - someone who is not as persistent as I and
>> willing to dive into the source code would never know from the current
>> documentation of either XMLResource.OPTION_LAX_FEATURE_PROCESSING or
>> XMLResource.OPTION_EXTENDED_META_DATA.
> It is intentionally working this way but the documentation is indeed
> sadly deficient. At the very least there should be an @see and some
> commentary to help in uninitiated. Feel free to open a bugzilla to
> enhance the Javadoc... I'll ask Dave to look at the book's descriptions
> of these options to make sure it's clear there...
>>
>> Eric
>>
>>
>>
>>> Eric Rizzo wrote:
>>>> I'm facing a situation where I would like to change the name of an
>>>> EAttribute in my model but am not allowed to break existing model
>>>> instances. So I need the XML deserialization to be tolerant of the
>>>> old name and convert it to the new name for the in-memory model (and
>>>> subsequently use the new name when serializing back to XML).
>>>> Is this something that the extendedMetaData EAnnotation can help with?
>>>> Is there any other option other than writing my own serialization impl?
>>>>
>>>> TIA,
>>>> Eric
>>>
|
|
|
Powered by
FUDForum. Page generated in 0.03641 seconds
] 
Search
Help
Register
Login
Home
