Home » Modeling » EMF » [EMF] UUID of EObject
| | | |
| Re: [EMF] UUID of EObject [message #686822 is a reply to message #686821] |
Fri, 20 May 2011 14:49   |
 Rimvydas
Messages: 47
Registered: July 2009 |
Member |
|
|
org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
After unload the object will be attached to the resource of container
and after that detached from it's old resource. At the attaching time
DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID will
generated.
On 5/20/2011 5:24 PM, Ed Merks wrote:
> Rimvydas,
>
> I'm just taking your word on the behavior you're describing. In general
> when an object is removed from a resource that assigns UUIDs I'd expect
> this code in XMLResourceImpl to kick in:
>
> protected void detachedHelper(EObject eObject)
> {
> if (useIDs())
> {
> if (useUUIDs())
> {
> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
> }
>
> if (idToEObjectMap != null && eObjectToIDMap != null)
> {
> setID(eObject, null);
> }
> }
>
> super.detachedHelper(eObject);
> }
>
> Similarly, when an object is attached, this kicks in:
>
> protected void attachedHelper(EObject eObject)
> {
> super.attachedHelper(eObject);
>
> if (useIDs())
> {
> String id = getID(eObject);
> if (useUUIDs() && id == null)
> {
> if (assignIDsWhileLoading() || !isLoading())
> {
> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
> if (id == null)
> {
> id = EcoreUtil.generateUUID();
> }
> setID(eObject, id);
> }
> }
> else if (id != null)
> {
> getIDToEObjectMap().put(id, eObject);
> }
> }
> }
>
> I.e., generally the UUID is preserved when you move objects from one
> resource to another.
>
> I'm not sure if this is applicable for the case you have. You've not
> said anything about which resource implementation you're using...
>
>
> Rimvydas Vaidelis wrote:
>>> If you asked objectB.eResource() it would be resourceA so it's
>>> reasonable that resourceA would assign an ID for an object it contains.
>>
>> [Rimvydas]: Is it OK that the object has another ID ?
>>
|
|
|
| Re: [EMF] UUID of EObject [message #686823 is a reply to message #686822] |
Fri, 20 May 2011 15:24 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Rimvydas,
Comments below.
Rimvydas Vaidelis wrote:
> org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
> After unload the object will be attached to the resource of container
You mean during?
> and after that detached from it's old resource.
So it would be better to do these in the opposite order?
// If we're not setting a new resource, attach it to the old
container's resource.
if (resource == null)
{
oldContainerResource.attached(this);
}
// If we didn't detach it from an old resource already, detach
it from the old container's resource.
//
else if (oldResource == null)
{
oldContainerResource.detached(this);
}
We do generate do removes before adds:
notifications = eBasicRemoveFromContainer(notifications);
notifications = eBasicSetContainer(null, -1, notifications);
I wonder if changing it would be bad for anyone...
> At the attaching time
> DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID will
> generated.
>
> On 5/20/2011 5:24 PM, Ed Merks wrote:
>> Rimvydas,
>>
>> I'm just taking your word on the behavior you're describing. In general
>> when an object is removed from a resource that assigns UUIDs I'd expect
>> this code in XMLResourceImpl to kick in:
>>
>> protected void detachedHelper(EObject eObject)
>> {
>> if (useIDs())
>> {
>> if (useUUIDs())
>> {
>> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
>> }
>>
>> if (idToEObjectMap != null && eObjectToIDMap != null)
>> {
>> setID(eObject, null);
>> }
>> }
>>
>> super.detachedHelper(eObject);
>> }
>>
>> Similarly, when an object is attached, this kicks in:
>>
>> protected void attachedHelper(EObject eObject)
>> {
>> super.attachedHelper(eObject);
>>
>> if (useIDs())
>> {
>> String id = getID(eObject);
>> if (useUUIDs() && id == null)
>> {
>> if (assignIDsWhileLoading() || !isLoading())
>> {
>> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
>> if (id == null)
>> {
>> id = EcoreUtil.generateUUID();
>> }
>> setID(eObject, id);
>> }
>> }
>> else if (id != null)
>> {
>> getIDToEObjectMap().put(id, eObject);
>> }
>> }
>> }
>>
>> I.e., generally the UUID is preserved when you move objects from one
>> resource to another.
>>
>> I'm not sure if this is applicable for the case you have. You've not
>> said anything about which resource implementation you're using...
>>
>>
>> Rimvydas Vaidelis wrote:
>>>> If you asked objectB.eResource() it would be resourceA so it's
>>>> reasonable that resourceA would assign an ID for an object it
>>>> contains.
>>>
>>> [Rimvydas]: Is it OK that the object has another ID ?
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] UUID of EObject [message #686824 is a reply to message #686823] |
Fri, 20 May 2011 15:46 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Maybe you could save me some time and make a small test case showing the
problem so I can look in more detail? Likely you can use
EPackage.eClassifiers for the model instance as it supports proxy
resolving containment...
Ed Merks wrote:
> Rimvydas,
>
> Comments below.
>
> Rimvydas Vaidelis wrote:
>> org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
>> After unload the object will be attached to the resource of container
> You mean during?
>> and after that detached from it's old resource.
> So it would be better to do these in the opposite order?
>
> // If we're not setting a new resource, attach it to the old
> container's resource.
> if (resource == null)
> {
> oldContainerResource.attached(this);
> }
> // If we didn't detach it from an old resource already,
> detach it from the old container's resource.
> //
> else if (oldResource == null)
> {
> oldContainerResource.detached(this);
> }
>
> We do generate do removes before adds:
>
> notifications = eBasicRemoveFromContainer(notifications);
> notifications = eBasicSetContainer(null, -1, notifications);
>
> I wonder if changing it would be bad for anyone...
>> At the attaching time
>> DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID
>> will generated.
>>
>> On 5/20/2011 5:24 PM, Ed Merks wrote:
>>> Rimvydas,
>>>
>>> I'm just taking your word on the behavior you're describing. In general
>>> when an object is removed from a resource that assigns UUIDs I'd expect
>>> this code in XMLResourceImpl to kick in:
>>>
>>> protected void detachedHelper(EObject eObject)
>>> {
>>> if (useIDs())
>>> {
>>> if (useUUIDs())
>>> {
>>> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
>>> }
>>>
>>> if (idToEObjectMap != null && eObjectToIDMap != null)
>>> {
>>> setID(eObject, null);
>>> }
>>> }
>>>
>>> super.detachedHelper(eObject);
>>> }
>>>
>>> Similarly, when an object is attached, this kicks in:
>>>
>>> protected void attachedHelper(EObject eObject)
>>> {
>>> super.attachedHelper(eObject);
>>>
>>> if (useIDs())
>>> {
>>> String id = getID(eObject);
>>> if (useUUIDs() && id == null)
>>> {
>>> if (assignIDsWhileLoading() || !isLoading())
>>> {
>>> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
>>> if (id == null)
>>> {
>>> id = EcoreUtil.generateUUID();
>>> }
>>> setID(eObject, id);
>>> }
>>> }
>>> else if (id != null)
>>> {
>>> getIDToEObjectMap().put(id, eObject);
>>> }
>>> }
>>> }
>>>
>>> I.e., generally the UUID is preserved when you move objects from one
>>> resource to another.
>>>
>>> I'm not sure if this is applicable for the case you have. You've not
>>> said anything about which resource implementation you're using...
>>>
>>>
>>> Rimvydas Vaidelis wrote:
>>>>> If you asked objectB.eResource() it would be resourceA so it's
>>>>> reasonable that resourceA would assign an ID for an object it
>>>>> contains.
>>>>
>>>> [Rimvydas]: Is it OK that the object has another ID ?
>>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] UUID of EObject [message #686826 is a reply to message #686823] |
Fri, 20 May 2011 16:33 |
Rimvydas
Messages: 47
Registered: July 2009 |
Member |
|
|
Yes. I mean during the unload.
I have investigated the code in more detail. The object will be attached
to the resource of container but it will not be detached
from old resource. I think that it should be detached from old resource
before attaching it to the new resource.
On 5/20/2011 6:24 PM, Ed Merks wrote:
> Rimvydas,
>
> Comments below.
>
> Rimvydas Vaidelis wrote:
>> org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
>> After unload the object will be attached to the resource of container
> You mean during?
>> and after that detached from it's old resource.
> So it would be better to do these in the opposite order?
>
> // If we're not setting a new resource, attach it to the old container's
> resource.
> if (resource == null)
> {
> oldContainerResource.attached(this);
> }
> // If we didn't detach it from an old resource already, detach it from
> the old container's resource.
> //
> else if (oldResource == null)
> {
> oldContainerResource.detached(this);
> }
>
> We do generate do removes before adds:
>
> notifications = eBasicRemoveFromContainer(notifications);
> notifications = eBasicSetContainer(null, -1, notifications);
>
> I wonder if changing it would be bad for anyone...
>> At the attaching time
>> DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID will
>> generated.
>>
>> On 5/20/2011 5:24 PM, Ed Merks wrote:
>>> Rimvydas,
>>>
>>> I'm just taking your word on the behavior you're describing. In general
>>> when an object is removed from a resource that assigns UUIDs I'd expect
>>> this code in XMLResourceImpl to kick in:
>>>
>>> protected void detachedHelper(EObject eObject)
>>> {
>>> if (useIDs())
>>> {
>>> if (useUUIDs())
>>> {
>>> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
>>> }
>>>
>>> if (idToEObjectMap != null && eObjectToIDMap != null)
>>> {
>>> setID(eObject, null);
>>> }
>>> }
>>>
>>> super.detachedHelper(eObject);
>>> }
>>>
>>> Similarly, when an object is attached, this kicks in:
>>>
>>> protected void attachedHelper(EObject eObject)
>>> {
>>> super.attachedHelper(eObject);
>>>
>>> if (useIDs())
>>> {
>>> String id = getID(eObject);
>>> if (useUUIDs() && id == null)
>>> {
>>> if (assignIDsWhileLoading() || !isLoading())
>>> {
>>> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
>>> if (id == null)
>>> {
>>> id = EcoreUtil.generateUUID();
>>> }
>>> setID(eObject, id);
>>> }
>>> }
>>> else if (id != null)
>>> {
>>> getIDToEObjectMap().put(id, eObject);
>>> }
>>> }
>>> }
>>>
>>> I.e., generally the UUID is preserved when you move objects from one
>>> resource to another.
>>>
>>> I'm not sure if this is applicable for the case you have. You've not
>>> said anything about which resource implementation you're using...
>>>
>>>
>>> Rimvydas Vaidelis wrote:
>>>>> If you asked objectB.eResource() it would be resourceA so it's
>>>>> reasonable that resourceA would assign an ID for an object it
>>>>> contains.
>>>>
>>>> [Rimvydas]: Is it OK that the object has another ID ?
>>>>
>>
|
|
|
| Re: [EMF] UUID of EObject [message #686827 is a reply to message #686824] |
Fri, 20 May 2011 16:39 |
Rimvydas
Messages: 47
Registered: July 2009 |
Member |
|
|
I already have the unit test. Where can I place the zip ?
On 5/20/2011 6:46 PM, Ed Merks wrote:
> Maybe you could save me some time and make a small test case showing the
> problem so I can look in more detail? Likely you can use
> EPackage.eClassifiers for the model instance as it supports proxy
> resolving containment...
>
>
> Ed Merks wrote:
>> Rimvydas,
>>
>> Comments below.
>>
>> Rimvydas Vaidelis wrote:
>>> org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
>>> After unload the object will be attached to the resource of container
>> You mean during?
>>> and after that detached from it's old resource.
>> So it would be better to do these in the opposite order?
>>
>> // If we're not setting a new resource, attach it to the old
>> container's resource.
>> if (resource == null)
>> {
>> oldContainerResource.attached(this);
>> }
>> // If we didn't detach it from an old resource already, detach it from
>> the old container's resource.
>> //
>> else if (oldResource == null)
>> {
>> oldContainerResource.detached(this);
>> }
>>
>> We do generate do removes before adds:
>>
>> notifications = eBasicRemoveFromContainer(notifications);
>> notifications = eBasicSetContainer(null, -1, notifications);
>>
>> I wonder if changing it would be bad for anyone...
>>> At the attaching time
>>> DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID
>>> will generated.
>>>
>>> On 5/20/2011 5:24 PM, Ed Merks wrote:
>>>> Rimvydas,
>>>>
>>>> I'm just taking your word on the behavior you're describing. In general
>>>> when an object is removed from a resource that assigns UUIDs I'd expect
>>>> this code in XMLResourceImpl to kick in:
>>>>
>>>> protected void detachedHelper(EObject eObject)
>>>> {
>>>> if (useIDs())
>>>> {
>>>> if (useUUIDs())
>>>> {
>>>> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
>>>> }
>>>>
>>>> if (idToEObjectMap != null && eObjectToIDMap != null)
>>>> {
>>>> setID(eObject, null);
>>>> }
>>>> }
>>>>
>>>> super.detachedHelper(eObject);
>>>> }
>>>>
>>>> Similarly, when an object is attached, this kicks in:
>>>>
>>>> protected void attachedHelper(EObject eObject)
>>>> {
>>>> super.attachedHelper(eObject);
>>>>
>>>> if (useIDs())
>>>> {
>>>> String id = getID(eObject);
>>>> if (useUUIDs() && id == null)
>>>> {
>>>> if (assignIDsWhileLoading() || !isLoading())
>>>> {
>>>> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
>>>> if (id == null)
>>>> {
>>>> id = EcoreUtil.generateUUID();
>>>> }
>>>> setID(eObject, id);
>>>> }
>>>> }
>>>> else if (id != null)
>>>> {
>>>> getIDToEObjectMap().put(id, eObject);
>>>> }
>>>> }
>>>> }
>>>>
>>>> I.e., generally the UUID is preserved when you move objects from one
>>>> resource to another.
>>>>
>>>> I'm not sure if this is applicable for the case you have. You've not
>>>> said anything about which resource implementation you're using...
>>>>
>>>>
>>>> Rimvydas Vaidelis wrote:
>>>>>> If you asked objectB.eResource() it would be resourceA so it's
>>>>>> reasonable that resourceA would assign an ID for an object it
>>>>>> contains.
>>>>>
>>>>> [Rimvydas]: Is it OK that the object has another ID ?
>>>>>
>>>
|
|
| |
| Re: [EMF] UUID of EObject [message #686830 is a reply to message #686828] |
Sat, 21 May 2011 15:42 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Rimvydas,
All other issues aside, detached not being called seems wrong. Please
open a bugzilla with this test case. (It has an unnecessary dependency
on CDO.)
Rimvydas Vaidelis wrote:
> See the attached zip.
>
> On 5/20/2011 6:46 PM, Ed Merks wrote:
>> Maybe you could save me some time and make a small test case showing the
>> problem so I can look in more detail? Likely you can use
>> EPackage.eClassifiers for the model instance as it supports proxy
>> resolving containment...
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] UUID of EObject [message #686996 is a reply to message #686816] |
Fri, 20 May 2011 13:16 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Rimvydas,
Comments below.
Rimvydas Vaidelis wrote:
> Hi,
>
> I have a model with enabled containment proxies. Object objectA is
> added into contents of resourceA and object objectB is added into
> contents of resourceB. objectA contains objectB. Both resources use
> UUIDs. After unload of resourceB all contained objects are attached to
> resourceA.
Yes, B will be a proxy.
> ID of objectB in resourceB before resourceB unload and ID of objectB
> in resourceA after resourceB unload are different.
I'm not sure it matters given that objectB is a proxy.
>
> Is this normal and why ?
If you asked objectB.eResource() it would be resourceA so it's
reasonable that resourceA would assign an ID for an object it contains.
>
> Thanks in advance,
>
> Rimvydas
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: [EMF] UUID of EObject [message #687001 is a reply to message #686820] |
Fri, 20 May 2011 14:24 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Rimvydas,<br>
<br>
I'm just taking your word on the behavior you're describing. In
general when an object is removed from a resource that assigns UUIDs
I'd expect this code in XMLResourceImpl to kick in:<br>
<blockquote><small> protected void detachedHelper(EObject eObject)</small><br>
<small> {</small><br>
<small> if (useIDs())</small><br>
<small> {</small><br>
<small> if (useUUIDs())</small><br>
<small> {</small><br>
<small> <b>DETACHED_EOBJECT_TO_ID_MAP.put(eObject,
getID(eObject));</b></small><br>
<small> }</small><br>
<br>
<small> if (idToEObjectMap != null && eObjectToIDMap !=
null)</small><br>
<small> {</small><br>
<small> setID(eObject, null);</small><br>
<small> }</small><br>
<small> }</small><br>
<small> </small><br>
<small> super.detachedHelper(eObject);</small><br>
<small> }</small><br>
</blockquote>
Similarly, when an object is attached, this kicks in:<br>
<blockquote><small> protected void attachedHelper(EObject eObject)</small><br>
<small> {</small><br>
<small> super.attachedHelper(eObject);</small><br>
<small> </small><br>
<small> if (useIDs())</small><br>
<small> {</small><br>
<small> String id = getID(eObject);</small><br>
<small> if (useUUIDs() && id == null)</small><br>
<small> {</small><br>
<small> if (assignIDsWhileLoading() || !isLoading())</small><br>
<small> {</small><br>
<b><small> id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);</small></b><br>
<small> if (id == null)</small><br>
<small> {</small><br>
<small> id = EcoreUtil.generateUUID();</small><br>
<small> }</small><br>
<small> setID(eObject, id);</small><br>
<small> }</small><br>
<small> }</small><br>
<small> else if (id != null)</small><br>
<small> {</small><br>
<small> getIDToEObjectMap().put(id, eObject);</small><br>
<small> }</small><br>
<small> }</small><br>
<small> }</small><br>
</blockquote>
I.e., generally the UUID is preserved when you move objects from one
resource to another.<br>
<br>
I'm not sure if this is applicable for the case you have. You've not
said anything about which resource implementation you're using...<br>
<br>
<br>
Rimvydas Vaidelis wrote:
<blockquote cite="mid:ir5s8b$d0v$1@news.eclipse.org" type="cite">
<blockquote type="cite">If you asked objectB.eResource() it would be
resourceA so it's
<br>
reasonable that resourceA would assign an ID for an object it contains.
<br>
</blockquote>
<br>
[Rimvydas]: Is it OK that the object has another ID ?
<br>
<br>
</blockquote>
</body>
</html>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] UUID of EObject [message #687002 is a reply to message #686821] |
Fri, 20 May 2011 14:49 |
Rimvydas
Messages: 47
Registered: July 2009 |
Member |
|
|
org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
After unload the object will be attached to the resource of container
and after that detached from it's old resource. At the attaching time
DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID will
generated.
On 5/20/2011 5:24 PM, Ed Merks wrote:
> Rimvydas,
>
> I'm just taking your word on the behavior you're describing. In general
> when an object is removed from a resource that assigns UUIDs I'd expect
> this code in XMLResourceImpl to kick in:
>
> protected void detachedHelper(EObject eObject)
> {
> if (useIDs())
> {
> if (useUUIDs())
> {
> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
> }
>
> if (idToEObjectMap != null && eObjectToIDMap != null)
> {
> setID(eObject, null);
> }
> }
>
> super.detachedHelper(eObject);
> }
>
> Similarly, when an object is attached, this kicks in:
>
> protected void attachedHelper(EObject eObject)
> {
> super.attachedHelper(eObject);
>
> if (useIDs())
> {
> String id = getID(eObject);
> if (useUUIDs() && id == null)
> {
> if (assignIDsWhileLoading() || !isLoading())
> {
> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
> if (id == null)
> {
> id = EcoreUtil.generateUUID();
> }
> setID(eObject, id);
> }
> }
> else if (id != null)
> {
> getIDToEObjectMap().put(id, eObject);
> }
> }
> }
>
> I.e., generally the UUID is preserved when you move objects from one
> resource to another.
>
> I'm not sure if this is applicable for the case you have. You've not
> said anything about which resource implementation you're using...
>
>
> Rimvydas Vaidelis wrote:
>>> If you asked objectB.eResource() it would be resourceA so it's
>>> reasonable that resourceA would assign an ID for an object it contains.
>>
>> [Rimvydas]: Is it OK that the object has another ID ?
>>
|
|
|
| Re: [EMF] UUID of EObject [message #687003 is a reply to message #686822] |
Fri, 20 May 2011 15:24 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Rimvydas,
Comments below.
Rimvydas Vaidelis wrote:
> org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
> After unload the object will be attached to the resource of container
You mean during?
> and after that detached from it's old resource.
So it would be better to do these in the opposite order?
// If we're not setting a new resource, attach it to the old
container's resource.
if (resource == null)
{
oldContainerResource.attached(this);
}
// If we didn't detach it from an old resource already, detach
it from the old container's resource.
//
else if (oldResource == null)
{
oldContainerResource.detached(this);
}
We do generate do removes before adds:
notifications = eBasicRemoveFromContainer(notifications);
notifications = eBasicSetContainer(null, -1, notifications);
I wonder if changing it would be bad for anyone...
> At the attaching time
> DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID will
> generated.
>
> On 5/20/2011 5:24 PM, Ed Merks wrote:
>> Rimvydas,
>>
>> I'm just taking your word on the behavior you're describing. In general
>> when an object is removed from a resource that assigns UUIDs I'd expect
>> this code in XMLResourceImpl to kick in:
>>
>> protected void detachedHelper(EObject eObject)
>> {
>> if (useIDs())
>> {
>> if (useUUIDs())
>> {
>> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
>> }
>>
>> if (idToEObjectMap != null && eObjectToIDMap != null)
>> {
>> setID(eObject, null);
>> }
>> }
>>
>> super.detachedHelper(eObject);
>> }
>>
>> Similarly, when an object is attached, this kicks in:
>>
>> protected void attachedHelper(EObject eObject)
>> {
>> super.attachedHelper(eObject);
>>
>> if (useIDs())
>> {
>> String id = getID(eObject);
>> if (useUUIDs() && id == null)
>> {
>> if (assignIDsWhileLoading() || !isLoading())
>> {
>> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
>> if (id == null)
>> {
>> id = EcoreUtil.generateUUID();
>> }
>> setID(eObject, id);
>> }
>> }
>> else if (id != null)
>> {
>> getIDToEObjectMap().put(id, eObject);
>> }
>> }
>> }
>>
>> I.e., generally the UUID is preserved when you move objects from one
>> resource to another.
>>
>> I'm not sure if this is applicable for the case you have. You've not
>> said anything about which resource implementation you're using...
>>
>>
>> Rimvydas Vaidelis wrote:
>>>> If you asked objectB.eResource() it would be resourceA so it's
>>>> reasonable that resourceA would assign an ID for an object it
>>>> contains.
>>>
>>> [Rimvydas]: Is it OK that the object has another ID ?
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] UUID of EObject [message #687005 is a reply to message #686823] |
Fri, 20 May 2011 15:46 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Maybe you could save me some time and make a small test case showing the
problem so I can look in more detail? Likely you can use
EPackage.eClassifiers for the model instance as it supports proxy
resolving containment...
Ed Merks wrote:
> Rimvydas,
>
> Comments below.
>
> Rimvydas Vaidelis wrote:
>> org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
>> After unload the object will be attached to the resource of container
> You mean during?
>> and after that detached from it's old resource.
> So it would be better to do these in the opposite order?
>
> // If we're not setting a new resource, attach it to the old
> container's resource.
> if (resource == null)
> {
> oldContainerResource.attached(this);
> }
> // If we didn't detach it from an old resource already,
> detach it from the old container's resource.
> //
> else if (oldResource == null)
> {
> oldContainerResource.detached(this);
> }
>
> We do generate do removes before adds:
>
> notifications = eBasicRemoveFromContainer(notifications);
> notifications = eBasicSetContainer(null, -1, notifications);
>
> I wonder if changing it would be bad for anyone...
>> At the attaching time
>> DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID
>> will generated.
>>
>> On 5/20/2011 5:24 PM, Ed Merks wrote:
>>> Rimvydas,
>>>
>>> I'm just taking your word on the behavior you're describing. In general
>>> when an object is removed from a resource that assigns UUIDs I'd expect
>>> this code in XMLResourceImpl to kick in:
>>>
>>> protected void detachedHelper(EObject eObject)
>>> {
>>> if (useIDs())
>>> {
>>> if (useUUIDs())
>>> {
>>> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
>>> }
>>>
>>> if (idToEObjectMap != null && eObjectToIDMap != null)
>>> {
>>> setID(eObject, null);
>>> }
>>> }
>>>
>>> super.detachedHelper(eObject);
>>> }
>>>
>>> Similarly, when an object is attached, this kicks in:
>>>
>>> protected void attachedHelper(EObject eObject)
>>> {
>>> super.attachedHelper(eObject);
>>>
>>> if (useIDs())
>>> {
>>> String id = getID(eObject);
>>> if (useUUIDs() && id == null)
>>> {
>>> if (assignIDsWhileLoading() || !isLoading())
>>> {
>>> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
>>> if (id == null)
>>> {
>>> id = EcoreUtil.generateUUID();
>>> }
>>> setID(eObject, id);
>>> }
>>> }
>>> else if (id != null)
>>> {
>>> getIDToEObjectMap().put(id, eObject);
>>> }
>>> }
>>> }
>>>
>>> I.e., generally the UUID is preserved when you move objects from one
>>> resource to another.
>>>
>>> I'm not sure if this is applicable for the case you have. You've not
>>> said anything about which resource implementation you're using...
>>>
>>>
>>> Rimvydas Vaidelis wrote:
>>>>> If you asked objectB.eResource() it would be resourceA so it's
>>>>> reasonable that resourceA would assign an ID for an object it
>>>>> contains.
>>>>
>>>> [Rimvydas]: Is it OK that the object has another ID ?
>>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] UUID of EObject [message #687007 is a reply to message #686823] |
Fri, 20 May 2011 16:33 |
Rimvydas
Messages: 47
Registered: July 2009 |
Member |
|
|
Yes. I mean during the unload.
I have investigated the code in more detail. The object will be attached
to the resource of container but it will not be detached
from old resource. I think that it should be detached from old resource
before attaching it to the new resource.
On 5/20/2011 6:24 PM, Ed Merks wrote:
> Rimvydas,
>
> Comments below.
>
> Rimvydas Vaidelis wrote:
>> org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
>> After unload the object will be attached to the resource of container
> You mean during?
>> and after that detached from it's old resource.
> So it would be better to do these in the opposite order?
>
> // If we're not setting a new resource, attach it to the old container's
> resource.
> if (resource == null)
> {
> oldContainerResource.attached(this);
> }
> // If we didn't detach it from an old resource already, detach it from
> the old container's resource.
> //
> else if (oldResource == null)
> {
> oldContainerResource.detached(this);
> }
>
> We do generate do removes before adds:
>
> notifications = eBasicRemoveFromContainer(notifications);
> notifications = eBasicSetContainer(null, -1, notifications);
>
> I wonder if changing it would be bad for anyone...
>> At the attaching time
>> DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID will
>> generated.
>>
>> On 5/20/2011 5:24 PM, Ed Merks wrote:
>>> Rimvydas,
>>>
>>> I'm just taking your word on the behavior you're describing. In general
>>> when an object is removed from a resource that assigns UUIDs I'd expect
>>> this code in XMLResourceImpl to kick in:
>>>
>>> protected void detachedHelper(EObject eObject)
>>> {
>>> if (useIDs())
>>> {
>>> if (useUUIDs())
>>> {
>>> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
>>> }
>>>
>>> if (idToEObjectMap != null && eObjectToIDMap != null)
>>> {
>>> setID(eObject, null);
>>> }
>>> }
>>>
>>> super.detachedHelper(eObject);
>>> }
>>>
>>> Similarly, when an object is attached, this kicks in:
>>>
>>> protected void attachedHelper(EObject eObject)
>>> {
>>> super.attachedHelper(eObject);
>>>
>>> if (useIDs())
>>> {
>>> String id = getID(eObject);
>>> if (useUUIDs() && id == null)
>>> {
>>> if (assignIDsWhileLoading() || !isLoading())
>>> {
>>> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
>>> if (id == null)
>>> {
>>> id = EcoreUtil.generateUUID();
>>> }
>>> setID(eObject, id);
>>> }
>>> }
>>> else if (id != null)
>>> {
>>> getIDToEObjectMap().put(id, eObject);
>>> }
>>> }
>>> }
>>>
>>> I.e., generally the UUID is preserved when you move objects from one
>>> resource to another.
>>>
>>> I'm not sure if this is applicable for the case you have. You've not
>>> said anything about which resource implementation you're using...
>>>
>>>
>>> Rimvydas Vaidelis wrote:
>>>>> If you asked objectB.eResource() it would be resourceA so it's
>>>>> reasonable that resourceA would assign an ID for an object it
>>>>> contains.
>>>>
>>>> [Rimvydas]: Is it OK that the object has another ID ?
>>>>
>>
|
|
|
| Re: [EMF] UUID of EObject [message #687008 is a reply to message #686824] |
Fri, 20 May 2011 16:39 |
Rimvydas
Messages: 47
Registered: July 2009 |
Member |
|
|
I already have the unit test. Where can I place the zip ?
On 5/20/2011 6:46 PM, Ed Merks wrote:
> Maybe you could save me some time and make a small test case showing the
> problem so I can look in more detail? Likely you can use
> EPackage.eClassifiers for the model instance as it supports proxy
> resolving containment...
>
>
> Ed Merks wrote:
>> Rimvydas,
>>
>> Comments below.
>>
>> Rimvydas Vaidelis wrote:
>>> org.eclipse.emf.ecore.xmi.impl.XMIResourceImpl is used.
>>> After unload the object will be attached to the resource of container
>> You mean during?
>>> and after that detached from it's old resource.
>> So it would be better to do these in the opposite order?
>>
>> // If we're not setting a new resource, attach it to the old
>> container's resource.
>> if (resource == null)
>> {
>> oldContainerResource.attached(this);
>> }
>> // If we didn't detach it from an old resource already, detach it from
>> the old container's resource.
>> //
>> else if (oldResource == null)
>> {
>> oldContainerResource.detached(this);
>> }
>>
>> We do generate do removes before adds:
>>
>> notifications = eBasicRemoveFromContainer(notifications);
>> notifications = eBasicSetContainer(null, -1, notifications);
>>
>> I wonder if changing it would be bad for anyone...
>>> At the attaching time
>>> DETACHED_EOBJECT_TO_ID_MAP will not have the object so the new ID
>>> will generated.
>>>
>>> On 5/20/2011 5:24 PM, Ed Merks wrote:
>>>> Rimvydas,
>>>>
>>>> I'm just taking your word on the behavior you're describing. In general
>>>> when an object is removed from a resource that assigns UUIDs I'd expect
>>>> this code in XMLResourceImpl to kick in:
>>>>
>>>> protected void detachedHelper(EObject eObject)
>>>> {
>>>> if (useIDs())
>>>> {
>>>> if (useUUIDs())
>>>> {
>>>> *DETACHED_EOBJECT_TO_ID_MAP.put(eObject, getID(eObject));*
>>>> }
>>>>
>>>> if (idToEObjectMap != null && eObjectToIDMap != null)
>>>> {
>>>> setID(eObject, null);
>>>> }
>>>> }
>>>>
>>>> super.detachedHelper(eObject);
>>>> }
>>>>
>>>> Similarly, when an object is attached, this kicks in:
>>>>
>>>> protected void attachedHelper(EObject eObject)
>>>> {
>>>> super.attachedHelper(eObject);
>>>>
>>>> if (useIDs())
>>>> {
>>>> String id = getID(eObject);
>>>> if (useUUIDs() && id == null)
>>>> {
>>>> if (assignIDsWhileLoading() || !isLoading())
>>>> {
>>>> *id = DETACHED_EOBJECT_TO_ID_MAP.remove(eObject);*
>>>> if (id == null)
>>>> {
>>>> id = EcoreUtil.generateUUID();
>>>> }
>>>> setID(eObject, id);
>>>> }
>>>> }
>>>> else if (id != null)
>>>> {
>>>> getIDToEObjectMap().put(id, eObject);
>>>> }
>>>> }
>>>> }
>>>>
>>>> I.e., generally the UUID is preserved when you move objects from one
>>>> resource to another.
>>>>
>>>> I'm not sure if this is applicable for the case you have. You've not
>>>> said anything about which resource implementation you're using...
>>>>
>>>>
>>>> Rimvydas Vaidelis wrote:
>>>>>> If you asked objectB.eResource() it would be resourceA so it's
>>>>>> reasonable that resourceA would assign an ID for an object it
>>>>>> contains.
>>>>>
>>>>> [Rimvydas]: Is it OK that the object has another ID ?
>>>>>
>>>
|
|
| |
| Re: [EMF] UUID of EObject [message #687013 is a reply to message #686828] |
Sat, 21 May 2011 15:42 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Rimvydas,
All other issues aside, detached not being called seems wrong. Please
open a bugzilla with this test case. (It has an unnecessary dependency
on CDO.)
Rimvydas Vaidelis wrote:
> See the attached zip.
>
> On 5/20/2011 6:46 PM, Ed Merks wrote:
>> Maybe you could save me some time and make a small test case showing the
>> problem so I can look in more detail? Likely you can use
>> EPackage.eClassifiers for the model instance as it supports proxy
>> resolving containment...
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 11:32:20 GMT 2024
Powered by FUDForum. Page generated in 0.03425 seconds |
] 
Search
Help
Register
Login
Home
