| Problem with aliasings of ID values [message #418442] |
Wed, 16 April 2008 12:26  |
 Victor Sanchez
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Hello!
I have stumbled upon an aliasing problem when dealing with an attribute
with its ID set to true in the core model for a particular class
hierarchy. The situation is the following. Consider an EClass hierarchy
with 'NamedElement' as its root. As expected, this NamedElement has an
EAttribute of type EString, and incidentally, its ID has been set to 'true'.
Now, suppose that we create two subclasses from NamedElement, namely 'A'
and 'B', and 'A' has a non-containment reference to 'B'. Now if a model is
created where both instances of 'A' and 'B' share the same name, and
the 'B' instance is set as the value of that reference for the 'A'
instance, the Editor gets confused and outputs the following exception:
org.eclipse.emf.ecore.xmi.IllegalValueException: Value 'IDAliasing.impl.ModelImpl@166e555 (name: hello)' is not legal. (platform:/resource/test/My.idaliasing, 3, 58)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XM LHandler.java:2637)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XM LHandler.java:2622)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId(XML Handler.java:2778)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setAttribValue(XML Handler.java:2695)
at
org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler.handleObjectAtt ribs(SAXXMIHandler.java:85)
....
Also the reference to 'B' from 'A' appears void in the Properties View.
What I don't know is if this is what is expected for this case, or the
Editor could be capable of properly identify the static type encoded
for the reference and search only among the model elements that comply
with such type, which would seem to effectively avoid the aliasing that is
currently being produced. I also don't know if that would be compatible
with more general/complex cases.
A test case to reproduce this issue follows. It consists of a simple
core model and a conforming model that shows the explained problem. This
has been tested in EMF 2.4M5, but I'm pretty sure it also happens with EMF
2.3, at least.
Thank you very much!!!
Victor Sánchez
********************************
- IDAliasing.ecore:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="IDAliasing"
nsURI="http://IDAliasing" nsPrefix="idaliasing">
<eClassifiers xsi:type="ecore:EClass" name="NamedElement" abstract="true">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="A" eSuperTypes="#//NamedElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="b" eType="#//B"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="B" eSuperTypes="#//NamedElement"/>
<eClassifiers xsi:type="ecore:EClass" name="Model" eSuperTypes="#//NamedElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="items" upperBound="-1"
eType="#//NamedElement" containment="true"/>
</eClassifiers>
</ecore:EPackage>
********************************
- My.idaliasing:
<?xml version="1.0" encoding="UTF-8"?>
<idaliasing:Model xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:idaliasing="http://IDAliasing" name="hello">
<items xsi:type="idaliasing:A" name="hello" b="hello"/>
<items xsi:type="idaliasing:B" name="hello"/>
</idaliasing:Model>
|
|
|
| Re: Problem with aliasings of ID values [message #418446 is a reply to message #418442] |
Wed, 16 April 2008 13:38  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Victor,
Comments below.
Victor Sanchez wrote:
> Hello!
>
> I have stumbled upon an aliasing problem when dealing with an attribute
> with its ID set to true in the core model for a particular class
> hierarchy. The situation is the following. Consider an EClass hierarchy
> with 'NamedElement' as its root. As expected, this NamedElement has an
> EAttribute of type EString, and incidentally, its ID has been set to 'true'.
>
It seems likely that names might well not be unique across all objects
in a resource. Certainly ENamedElement.name in the Ecore model could
not be made an ID.
> Now, suppose that we create two subclasses from NamedElement, namely 'A'
> and 'B', and 'A' has a non-containment reference to 'B'. Now if a model is
> created where both instances of 'A' and 'B' share the same name, and
> the 'B' instance is set as the value of that reference for the 'A'
> instance, the Editor gets confused and outputs the following exception:
>
> org.eclipse.emf.ecore.xmi.IllegalValueException: Value 'IDAliasing.impl.ModelImpl@166e555 (name: hello)' is not legal. (platform:/resource/test/My.idaliasing, 3, 58)
> at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XM LHandler.java:2637)
> at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XM LHandler.java:2622)
> at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId(XML Handler.java:2778)
> at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setAttribValue(XML Handler.java:2695)
> at
> org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler.handleObjectAtt ribs(SAXXMIHandler.java:85)
> ....
>
Yep, I'd expect that. I doubt a "name" would really be an ID.
> Also the reference to 'B' from 'A' appears void in the Properties View.
>
You mean after the above exception? I'd expect that when the ID doesn't
resolve to an object of the correct type.
> What I don't know is if this is what is expected for this case, or the
> Editor could be capable of properly identify the static type encoded
> for the reference and search only among the model elements that comply
> with such type, which would seem to effectively avoid the aliasing that is
> currently being produced. I also don't know if that would be compatible
> with more general/complex cases.
>
No, that's not how IDs generally work. Resource.getEObject just takes a
string...
> A test case to reproduce this issue follows. It consists of a simple
> core model and a conforming model that shows the explained problem. This
> has been tested in EMF 2.4M5, but I'm pretty sure it also happens with EMF
> 2.3, at least.
>
> Thank you very much!!!
>
EMF does have support for EReference.eKeys, which might be more
appropriate...
> Victor Sánchez
>
> ********************************
> - IDAliasing.ecore:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="IDAliasing"
> nsURI="http://IDAliasing" nsPrefix="idaliasing">
> <eClassifiers xsi:type="ecore:EClass" name="NamedElement" abstract="true">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="A" eSuperTypes="#//NamedElement">
> <eStructuralFeatures xsi:type="ecore:EReference" name="b" eType="#//B"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="B" eSuperTypes="#//NamedElement"/>
> <eClassifiers xsi:type="ecore:EClass" name="Model" eSuperTypes="#//NamedElement">
> <eStructuralFeatures xsi:type="ecore:EReference" name="items" upperBound="-1"
> eType="#//NamedElement" containment="true"/>
> </eClassifiers>
> </ecore:EPackage>
>
> ********************************
> - My.idaliasing:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <idaliasing:Model xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:idaliasing="http://IDAliasing" name="hello">
> <items xsi:type="idaliasing:A" name="hello" b="hello"/>
> <items xsi:type="idaliasing:B" name="hello"/>
> </idaliasing:Model>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.01950 seconds
] 
Search
Help
Register
Login
Home
