| [OCLinEcore] eReference eKeys eOpposite [message #998772] |
Thu, 10 January 2013 12:13  |
Eclipse User |
|
|
|
Hi,
I have constructed a simple ecore meta-model describing a root model element comprising one or more node and link elements. Each node and link has a uuid attribute which has the ID property set to true. Each node has an 'incoming' and 'outgoing' reference to a link, and similarly, each link has a 'from' and 'to' reference to a node. I use eReferences and the eOpposite feature, thus ensuring that on model construction, when setting a reference, the reverse reference is set automatically. Further, I am setting the eKeys property to the uuid of the referring element for the references to provide more robust serialisation.
Creating a model (see below) based on the given ecore meta-model (see below) works as expected.
The problem is that I now wish to add OCL constraints into the meta-model. I have seen a similar topic raised (message #558058) where issues where identified using eKeys in OCLinEcore. However, this is different in that the key is an attribute within a different class.
Any assistance would be great!
Dan
****************** META-MODEL ********************
<?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="test1" nsURI="http://test1/1.0" nsPrefix="test1">
<eClassifiers xsi:type="ecore:EClass" name="Model">
<eStructuralFeatures xsi:type="ecore:EReference" name="node" upperBound="-1" eType="#//Node"
containment="true"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="link" upperBound="-1" eType="#//Link"
containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Node">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="uuid" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="outgoing" eType="#//Link"
eOpposite="#//Link/from" eKeys="#//Link/uuid"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="incoming" eType="#//Link"
eOpposite="#//Link/to" eKeys="#//Link/uuid"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Link">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="uuid" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
defaultValueLiteral="" iD="true"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="from" lowerBound="1" eType="#//Node"
eOpposite="#//Node/outgoing" eKeys="#//Node/uuid"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="to" lowerBound="1" eType="#//Node"
eOpposite="#//Node/incoming" eKeys="#//Node/uuid"/>
</eClassifiers>
</ecore:EPackage>
****************** SAMPLE MODEL ********************
<?xml version="1.0" encoding="ASCII"?>
<test1:Model
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:test1="http://test1/1.0"
xsi:schemaLocation="http://test1/1.0 test1.ecore">
<node uuid="n1"
outgoing="l1"/>
<node uuid="n2"
incoming="l1"/>
<link uuid="l1"
from="n1"
to="n2"/>
</test1:Model>
|
|
|
| Re: [OCLinEcore] eReference eKeys eOpposite [message #998862 is a reply to message #998772] |
Thu, 10 January 2013 16:01  |
| Eclipse User |
|
|
|
Hi
Your example demonstrates a new bug
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=397917) which can be
worked around by editing e.g.
property to#incoming : Node
{
key Node::uuid;
}
to remove the redundant qualification as
property to#incoming : Node
{
key uuid;
}
However, I think this is nothing to do with OCL. eKeys like xmi:id are
serialization detail not model content, so they are not naturally
accessible to OCL expressions.
You say you are doing this to "provide more robust serialisation".
Unless you are already an EMF expert, I would caution that you are
wasting your time by ignoring EMF's many built-in model-level
serialization capabilities such as UUIDs. If you want to improve
character-level integrity, add a checksum/error correcting
layer/encryption to your serialization. Using an unconventional approach
will make your serialization less robust as you uncover bugs in many of
the tools that you try to use.
Regards
Ed Willink
On 10/01/2013 17:13, Dan Simkins wrote:
> Hi,
>
> I have constructed a simple ecore meta-model describing a root model
> element comprising one or more node and link elements. Each node and
> link has a uuid attribute which has the ID property set to true. Each
> node has an 'incoming' and 'outgoing' reference to a link, and
> similarly, each link has a 'from' and 'to' reference to a node. I use
> eReferences and the eOpposite feature, thus ensuring that on model
> construction, when setting a reference, the reverse reference is set
> automatically. Further, I am setting the eKeys property to the uuid of
> the referring element for the references to provide more robust
> serialisation.
>
> Creating a model (see below) based on the given ecore meta-model (see
> below) works as expected.
>
> The problem is that I now wish to add OCL constraints into the
> meta-model. I have seen a similar topic raised (message #558058) where
> issues where identified using eKeys in OCLinEcore. However, this is
> different in that the key is an attribute within a different class.
>
> Any assistance would be great!
>
> Dan
>
> ****************** META-MODEL ********************
> <?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="test1"
> nsURI="http://test1/1.0" nsPrefix="test1">
> <eClassifiers xsi:type="ecore:EClass" name="Model">
> <eStructuralFeatures xsi:type="ecore:EReference" name="node"
> upperBound="-1" eType="#//Node"
> containment="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="link"
> upperBound="-1" eType="#//Link"
> containment="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Node">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="uuid"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="outgoing"
> eType="#//Link"
> eOpposite="#//Link/from" eKeys="#//Link/uuid"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="incoming"
> eType="#//Link"
> eOpposite="#//Link/to" eKeys="#//Link/uuid"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Link">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="uuid"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
> defaultValueLiteral="" iD="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="from"
> lowerBound="1" eType="#//Node"
> eOpposite="#//Node/outgoing" eKeys="#//Node/uuid"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="to"
> lowerBound="1" eType="#//Node"
> eOpposite="#//Node/incoming" eKeys="#//Node/uuid"/>
> </eClassifiers>
> </ecore:EPackage>
>
> ****************** SAMPLE MODEL ********************
> <?xml version="1.0" encoding="ASCII"?>
> <test1:Model
> xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:test1="http://test1/1.0"
> xsi:schemaLocation="http://test1/1.0 test1.ecore">
> <node uuid="n1"
> outgoing="l1"/>
> <node uuid="n2"
> incoming="l1"/>
> <link uuid="l1"
> from="n1"
> to="n2"/>
> </test1:Model>
|
|
|
|
|
|
| Re: [OCLinEcore] eReference eKeys eOpposite [message #999505 is a reply to message #999234] |
Sat, 12 January 2013 04:23 |
| Eclipse User |
|
|
|
Dan,
Yes, IDs take precedence. If an object has an ID attribute, that will
be (by default) what a resource implementation uses (should use, if
possible) for locating that object within its containing resource
resource. Note also that eKeys induce a constraint that the combination
of the key attributes are unique in that reference, and they only affect
serialization (by default) when they are defined on containment
references, that's because it's the path from the root of the resource
via containment references to the referenced object that's used in the
fragment path, and it's those segments which use the key, rather than
the index, to navigate to the appropriate child. That's why the place
you defined the eKeys in your model had no visible effect, and could
even be deterimental because any links referring to nodes in other
resources would all expect those nodes to have unique uuid attributes
but there's no constraint that says nodes in different resources can't
have the same ID. You can consider defining the eKeys on your
Model.node reference (and should rename it to nodes to reflect its
multiplicity).
On 11/01/2013 4:57 PM, Dan Simkins wrote:
> Hi Ed,
>
> Many thanks for your response. After a little more experimentation I
> have found that removal of the eKeys attribute from the eReferences
> using the ecore editor has no detrimental effect on serialisation - it
> is the setting of the ID attribute against the uuid that seems to
> force serialisation to use this uuid field. So, I am now happy as I
> can start to work in OCLinEcore!!
>
> Thanks again for your assistance!
>
> Dan
|
|
|
Powered by
FUDForum. Page generated in 0.06731 seconds
Home