|
| Re: [OCLinEcore] eReference eKeys eOpposite [message #998862 is a reply to message #998772] |
Thu, 10 January 2013 21:01   |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
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 09:23 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03644 seconds
] 
Search
Help
Register
Login
Home
