Home » Modeling » EMF » saving references in dynamically created emf
| saving references in dynamically created emf [message #899758] |
Thu, 02 August 2012 08:41  |
Eclipse User |
|
|
|
Hi,
when I store a statically (?) created EMF I get references like this (next)
<interactions xsi:type="uma:MouseInteraction" ObjectID="6a22778a"
signature=""
next="#//@methodPlugin.0/@methodPackage.0/@process/@breakdownElement.0/@interactionPatternModel/@interactionPatterns.0/@interactions.1"/>
in contrast in a dynamically created EMF I get references like this
(also next)
<interactions xsi:type="uma:MouseInteraction" ObjectID="3bd6bff7"
next="3bd6bff7" />
Can I change that (to the first variant) for dynamically created EMFs?
Greetings,
Ralf
|
|
| |
| Re: saving references in dynamically created emf [message #899907 is a reply to message #899891] |
Thu, 02 August 2012 18:57  |
| Eclipse User |
|
|
|
Hi Ed,
thanks ... as always you're right. The "targetReference" has a featureID
of -1. But why? I thought adding is to the StructuralFeatures of the
"targetClass" would set this automatically? Like this
targetReference = ecoreFactory.createEReference();
targetClass.getEStructuralFeatures().add(targetReference);
System.out.println(targetReference.getFeatureID()); --> "-1"
Or not?
Greetings,
Ralf
On 8/2/12 7:21 PM, Ed Merks wrote:
> Ralf,
>
> Might it be the case in the first variation that the referenced object
> doesn't have its ID feature set? If there is an ID, it will be used in
> favor of a fragment path regardless of dynamic or generated models...
>
>
> On 02/08/2012 10:41 AM, Ralf Buschermöhle wrote:
>> Hi,
>>
>> when I store a statically (?) created EMF I get references like this
>> (next)
>>
>> <interactions xsi:type="uma:MouseInteraction" ObjectID="6a22778a"
>> signature=""
>> next="#//@methodPlugin.0/@methodPackage.0/@process/@breakdownElement.0/@interactionPatternModel/@interactionPatterns.0/@interactions.1"/>
>>
>>
>> in contrast in a dynamically created EMF I get references like this
>> (also next)
>>
>> <interactions xsi:type="uma:MouseInteraction" ObjectID="3bd6bff7"
>> next="3bd6bff7" />
>>
>> Can I change that (to the first variant) for dynamically created EMFs?
>>
>> Greetings,
>>
>> Ralf
>
|
|
|
| Re: saving references in dynamically created emf [message #899909 is a reply to message #899907] |
Thu, 02 August 2012 19:08 |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ralf,
Comments below.
On 02/08/2012 8:57 PM, Ralf Buschermöhle wrote:
> Hi Ed,
>
> thanks ... as always you're right. The "targetReference" has a featureID
> of -1. But why? I thought adding is to the StructuralFeatures of the
> "targetClass" would set this automatically? Like this
>
> targetReference = ecoreFactory.createEReference();
> targetClass.getEStructuralFeatures().add(targetReference);
>
> System.out.println(targetReference.getFeatureID()); --> "-1"
>
> Or not?
No, the ID of the feature is set by the containing EClass and only when
it's needed, e.g., when calling EClass.getFeatureID. Only the ID of a
feature relative to a class is meaningful/useful. Because of multiple
inheritance, a feature's ID can be different relative to each EClass.
In any case, I don't think this is related.
In the end the resource decides the URI fragment with this method in
ResourceImpl:
public String getURIFragment(EObject eObject)
{
String id = EcoreUtil.getID(eObject);
if (id != null)
{
return id;
}
else
{
So if the object has an ID, it's used. If it doesn't a fragment path is
computed in the else case. So I would assume that in the first
serialization, the object doesn't have an ID (though it might have an ID
feature, it's not set) and in the second case, the ID feature is set to
the value you see.
>
> Greetings,
>
> Ralf
>
> On 8/2/12 7:21 PM, Ed Merks wrote:
>> Ralf,
>>
>> Might it be the case in the first variation that the referenced object
>> doesn't have its ID feature set? If there is an ID, it will be used in
>> favor of a fragment path regardless of dynamic or generated models...
>>
>>
>> On 02/08/2012 10:41 AM, Ralf Buschermöhle wrote:
>>> Hi,
>>>
>>> when I store a statically (?) created EMF I get references like this
>>> (next)
>>>
>>> <interactions xsi:type="uma:MouseInteraction" ObjectID="6a22778a"
>>> signature=""
>>> next="#//@methodPlugin.0/@methodPackage.0/@process/@breakdownElement.0/@interactionPatternModel/@interactionPatterns.0/@interactions.1"/>
>>>
>>>
>>> in contrast in a dynamically created EMF I get references like this
>>> (also next)
>>>
>>> <interactions xsi:type="uma:MouseInteraction" ObjectID="3bd6bff7"
>>> next="3bd6bff7" />
>>>
>>> Can I change that (to the first variant) for dynamically created EMFs?
>>>
>>> Greetings,
>>>
>>> Ralf
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: saving references in dynamically created emf [message #899955 is a reply to message #899909] |
Fri, 03 August 2012 07:53 |
| Eclipse User |
|
|
|
Hi Ed,
so ... the "problem" would be solved if I save the Dynamic EMF Model
(currently only the instantiated model is saved) in order to set the
FeatureIDs and have "correct" relationships in the saved instance?
Greetings,
Ralf
On 8/2/12 9:08 PM, Ed Merks wrote:
> Ralf,
>
> Comments below.
>
> On 02/08/2012 8:57 PM, Ralf Buschermöhle wrote:
>> Hi Ed,
>>
>> thanks ... as always you're right. The "targetReference" has a featureID
>> of -1. But why? I thought adding is to the StructuralFeatures of the
>> "targetClass" would set this automatically? Like this
>>
>> targetReference = ecoreFactory.createEReference();
>>
>> targetClass.getEStructuralFeatures().add(targetReference);
>>
>> System.out.println(targetReference.getFeatureID()); --> "-1"
>>
>> Or not?
> No, the ID of the feature is set by the containing EClass and only when
> it's needed, e.g., when calling EClass.getFeatureID. Only the ID of a
> feature relative to a class is meaningful/useful. Because of multiple
> inheritance, a feature's ID can be different relative to each EClass.
> In any case, I don't think this is related.
>
> In the end the resource decides the URI fragment with this method in
> ResourceImpl:
>
> public String getURIFragment(EObject eObject)
> {
> String id = EcoreUtil.getID(eObject);
> if (id != null)
> {
> return id;
> }
> else
> {
>
> So if the object has an ID, it's used. If it doesn't a fragment path is
> computed in the else case. So I would assume that in the first
> serialization, the object doesn't have an ID (though it might have an ID
> feature, it's not set) and in the second case, the ID feature is set to
> the value you see.
>
>>
>> Greetings,
>>
>> Ralf
>>
>> On 8/2/12 7:21 PM, Ed Merks wrote:
>>> Ralf,
>>>
>>> Might it be the case in the first variation that the referenced object
>>> doesn't have its ID feature set? If there is an ID, it will be used in
>>> favor of a fragment path regardless of dynamic or generated models...
>>>
>>>
>>> On 02/08/2012 10:41 AM, Ralf Buschermöhle wrote:
>>>> Hi,
>>>>
>>>> when I store a statically (?) created EMF I get references like this
>>>> (next)
>>>>
>>>> <interactions xsi:type="uma:MouseInteraction" ObjectID="6a22778a"
>>>> signature=""
>>>> next="#//@methodPlugin.0/@methodPackage.0/@process/@breakdownElement.0/@interactionPatternModel/@interactionPatterns.0/@interactions.1"/>
>>>>
>>>>
>>>>
>>>> in contrast in a dynamically created EMF I get references like this
>>>> (also next)
>>>>
>>>> <interactions xsi:type="uma:MouseInteraction" ObjectID="3bd6bff7"
>>>> next="3bd6bff7" />
>>>>
>>>> Can I change that (to the first variant) for dynamically created EMFs?
>>>>
>>>> Greetings,
>>>>
>>>> Ralf
>
|
|
|
| Re: saving references in dynamically created emf [message #900001 is a reply to message #899955] |
Fri, 03 August 2012 11:49 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ralf,
I don't think your problem has anything to do with feature IDs. Such IDs
are not used during serialization; only the feature name is relevant for
serialization. Your issue must have something to do with the instances
having an ID or not. Look at EcoreUtil.getID to see how the ID of an
instance is determined; set a breakpoint where I mentioned...
On 03/08/2012 9:53 AM, Ralf Buschermöhle wrote:
> Hi Ed,
>
> so ... the "problem" would be solved if I save the Dynamic EMF Model
> (currently only the instantiated model is saved) in order to set the
> FeatureIDs and have "correct" relationships in the saved instance?
>
> Greetings,
>
> Ralf
>
> On 8/2/12 9:08 PM, Ed Merks wrote:
>> Ralf,
>>
>> Comments below.
>>
>> On 02/08/2012 8:57 PM, Ralf Buschermöhle wrote:
>>> Hi Ed,
>>>
>>> thanks ... as always you're right. The "targetReference" has a featureID
>>> of -1. But why? I thought adding is to the StructuralFeatures of the
>>> "targetClass" would set this automatically? Like this
>>>
>>> targetReference = ecoreFactory.createEReference();
>>>
>>> targetClass.getEStructuralFeatures().add(targetReference);
>>>
>>> System.out.println(targetReference.getFeatureID()); --> "-1"
>>>
>>> Or not?
>> No, the ID of the feature is set by the containing EClass and only when
>> it's needed, e.g., when calling EClass.getFeatureID. Only the ID of a
>> feature relative to a class is meaningful/useful. Because of multiple
>> inheritance, a feature's ID can be different relative to each EClass.
>> In any case, I don't think this is related.
>>
>> In the end the resource decides the URI fragment with this method in
>> ResourceImpl:
>>
>> public String getURIFragment(EObject eObject)
>> {
>> String id = EcoreUtil.getID(eObject);
>> if (id != null)
>> {
>> return id;
>> }
>> else
>> {
>>
>> So if the object has an ID, it's used. If it doesn't a fragment path is
>> computed in the else case. So I would assume that in the first
>> serialization, the object doesn't have an ID (though it might have an ID
>> feature, it's not set) and in the second case, the ID feature is set to
>> the value you see.
>>
>>> Greetings,
>>>
>>> Ralf
>>>
>>> On 8/2/12 7:21 PM, Ed Merks wrote:
>>>> Ralf,
>>>>
>>>> Might it be the case in the first variation that the referenced object
>>>> doesn't have its ID feature set? If there is an ID, it will be used in
>>>> favor of a fragment path regardless of dynamic or generated models...
>>>>
>>>>
>>>> On 02/08/2012 10:41 AM, Ralf Buschermöhle wrote:
>>>>> Hi,
>>>>>
>>>>> when I store a statically (?) created EMF I get references like this
>>>>> (next)
>>>>>
>>>>> <interactions xsi:type="uma:MouseInteraction" ObjectID="6a22778a"
>>>>> signature=""
>>>>> next="#//@methodPlugin.0/@methodPackage.0/@process/@breakdownElement.0/@interactionPatternModel/@interactionPatterns.0/@interactions.1"/>
>>>>>
>>>>>
>>>>>
>>>>> in contrast in a dynamically created EMF I get references like this
>>>>> (also next)
>>>>>
>>>>> <interactions xsi:type="uma:MouseInteraction" ObjectID="3bd6bff7"
>>>>> next="3bd6bff7" />
>>>>>
>>>>> Can I change that (to the first variant) for dynamically created EMFs?
>>>>>
>>>>> Greetings,
>>>>>
>>>>> Ralf
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:13:38 GMT 2024
Powered by FUDForum. Page generated in 0.03939 seconds |
] 
Search
Help
Register
Login
Home
