Eclipse Community Forums: EMF » [EMF] UUID of EObject

Home » Modeling » EMF » [EMF] UUID of EObject

Fri, 20 May 2011 03:56

Eclipse User

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. ID
of objectB in resourceB before resourceB unload and ID of objectB in
resourceA after resourceB unload are different.

Is this normal and why ?

Thanks in advance,

Rimvydas

Re: [EMF] UUID of EObject [message #686817 is a reply to message #686816]

Fri, 20 May 2011 09:16

Eclipse User

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

Re: [EMF] UUID of EObject [message #686820 is a reply to message #686817]

Fri, 20 May 2011 10:10

Eclipse User

> 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 #686821 is a reply to message #686820]

Fri, 20 May 2011 10:24

Eclipse User

<!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, 
 
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: 
<blockquote>  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); 
  } 
</blockquote>
Similarly, when an object is attached, this kicks in: 
<blockquote>  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); 
      } 
    } 
  } 
</blockquote>
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:
<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
 
reasonable that resourceA would assign an ID for an object it contains.
 
</blockquote>
 
[Rimvydas]: Is it OK that the object has another ID ?
 
 
</blockquote>
</body>
</html>

Re: [EMF] UUID of EObject [message #686822 is a reply to message #686821]

Fri, 20 May 2011 10:49

Eclipse User

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 11:24

Eclipse User

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 #686824 is a reply to message #686823]

Fri, 20 May 2011 11:46

Eclipse User

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 #686826 is a reply to message #686823]

Fri, 20 May 2011 12:33

Eclipse User

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 12:39

Eclipse User

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 #686828 is a reply to message #686824]

Fri, 20 May 2011 13:00

Eclipse User

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...
>

Attachment: test.zip
(Size: 16.12KB, Downloaded 153 times)

Re: [EMF] UUID of EObject [message #686830 is a reply to message #686828]

Sat, 21 May 2011 11:42

Eclipse User

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...
>>

Re: [EMF] UUID of EObject [message #686996 is a reply to message #686816]

Fri, 20 May 2011 09:16

Eclipse User

Re: [EMF] UUID of EObject [message #687000 is a reply to message #686817]

Fri, 20 May 2011 10:10

Eclipse User

> 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 #687001 is a reply to message #686820]

Fri, 20 May 2011 10:24

Eclipse User