Home » Modeling » EMF » Delete changes containment proxy values
| Delete changes containment proxy values [message #546016] |
Fri, 09 July 2010 21:43  |
 Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Hello,
I've found what I think is an EMF bug, but I could be wrong. I have containment proxies enabled
and I have objectA in resource1 that has a containment reference to objectB that is in resource2.
If both of the objects are loaded and I delete objectA and then objectB, things work correctly.
However, if objectA has an EProxy for objectB and I delete objectA, then something
changes/munges/breaks the proxy URI for objectB. Then when I try to delete objectB, it fails
because the URI is wrong. I looked for the code that is making the change, but was unable to find it.
If I'm careful, I can reverse the behaviour (delete objectB before objectA) and it works around the
problem, but it seems to me that when you have containment proxies, deleting the container should
not alter the proxy's URI.
Is this a bug or am I missing something?
Thanks in advance.
Sincerely,
Stephen McCants
|
|
|
| Re: Delete changes containment proxy values [message #546064 is a reply to message #546016] |
Sat, 10 July 2010 16:03  |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stephen,
Comments below.
Stephen McCants wrote:
> Hello,
> I've found what I think is an EMF bug, but I could be wrong.
Probably. :-P
> I have containment proxies enabled and I have objectA in resource1
> that has a containment reference to objectB that is in resource2. If
> both of the objects are loaded and I delete objectA and then objectB,
> things work correctly.
As in delete command?
> However, if objectA has an EProxy for objectB and I delete
> objectA, then something changes/munges/breaks the proxy URI for objectB.
It changes from what to what?
> Then when I try to delete objectB, it fails because the URI is wrong.
Once objectA isn't contained by a resource set, proxies won't resolve
anymore.
> I looked for the code that is making the change, but was unable to
> find it.
Setting breakpoints you mean?
> If I'm careful, I can reverse the behaviour (delete objectB before
> objectA) and it works around the problem, but it seems to me that when
> you have containment proxies, deleting the container should not alter
> the proxy's URI.
There are so few places that call InternalEObject.eSetProxyURI that I
doubt this could be happening.
> Is this a bug or am I missing something?
I imagine that once you delete objectA you won't be able to resolve any
proxies that objectA references, containment or otherwise. So best to
ensure the proxies are resolved...
> Thanks in advance.
>
> Sincerely,
> Stephen McCants
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Delete changes containment proxy values [message #546424 is a reply to message #546064] |
Mon, 12 July 2010 17:11 |
Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for your reply. Here are my answers.
--Stephen
> Stephen McCants wrote:
>> Hello,
>> I've found what I think is an EMF bug, but I could be wrong.
> Probably. :-P
>> I have containment proxies enabled and I have objectA in resource1
>> that has a containment reference to objectB that is in resource2. If
>> both of the objects are loaded and I delete objectA and then objectB,
>> things work correctly.
> As in delete command?
resource.delete(null);
>> However, if objectA has an EProxy for objectB and I delete
>> objectA, then something changes/munges/breaks the proxy URI for objectB.
> It changes from what to what?
I'd have to rebreak my code to see exactly what it became. What it was doing was not obvious to me,
but it I think it was trying to make objectB a proxy that pointed into the parent resource for
resource1.
>> Then when I try to delete objectB, it fails because the URI is wrong.
> Once objectA isn't contained by a resource set, proxies won't resolve
> anymore.
Why not? Object B is a proxy to a different resource. That resource has not been deleted.
>> I looked for the code that is making the change, but was unable to
>> find it.
> Setting breakpoints you mean?
Yes.
>> If I'm careful, I can reverse the behaviour (delete objectB before
>> objectA) and it works around the problem, but it seems to me that when
>> you have containment proxies, deleting the container should not alter
>> the proxy's URI.
> There are so few places that call InternalEObject.eSetProxyURI that I
> doubt this could be happening.
Doubt what could be happening? Something is definitely changing the Proxy URI.
>> Is this a bug or am I missing something?
> I imagine that once you delete objectA you won't be able to resolve any
> proxies that objectA references, containment or otherwise. So best to
> ensure the proxies are resolved...
Easier said than done. Again, I don't see why the proxy URI would change. If the proxy URI doesn't
change, then the URI would still be resolvable and this problem would be avoided without having to
do extra work. After all, I don't necessarily know how many layers of proxies I need to walk
through and resolve.
If there are too many layers, it came become problematic since the bug only shows up when there are
unresolved proxies and then it becomes an order of operation problem. If the proxy URI doesn't
become munged, then the order of operation no longer matters.
|
|
|
| Re: Delete changes containment proxy values [message #546434 is a reply to message #546424] |
Mon, 12 July 2010 17:45 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stephen,
Comments below.
Stephen McCants wrote:
> Hi Ed,
> Thanks for your reply. Here are my answers.
>
> --Stephen
>
>> Stephen McCants wrote:
>>> Hello,
>>> I've found what I think is an EMF bug, but I could be wrong.
>> Probably. :-P
>>> I have containment proxies enabled and I have objectA in resource1
>>> that has a containment reference to objectB that is in resource2. If
>>> both of the objects are loaded and I delete objectA and then
>>> objectB, things work correctly.
>> As in delete command?
>
> resource.delete(null);
That will turn all contained objects into proxies. I.e.,
internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
where uri is the URI of the containing resource.
>
>>> However, if objectA has an EProxy for objectB and I delete
>>> objectA, then something changes/munges/breaks the proxy URI for
>>> objectB.
>> It changes from what to what?
>
> I'd have to rebreak my code to see exactly what it became. What it
> was doing was not obvious to me, but it I think it was trying to make
> objectB a proxy that pointed into the parent resource for resource1.
I'd expect it to use resource B.
>
>>> Then when I try to delete objectB, it fails because the URI is wrong.
>
>> Once objectA isn't contained by a resource set, proxies won't resolve
>> anymore.
>
> Why not? Object B is a proxy to a different resource. That resource
> has not been deleted.
The resource set needs to be reachable from the object (i.e.,
x.eResource() != null && x.eResource().getResourceSet() != null) for it
to be able to resolve proxies.
>
>>> I looked for the code that is making the change, but was unable to
>>> find it.
>> Setting breakpoints you mean?
>
> Yes.
>
>>> If I'm careful, I can reverse the behaviour (delete objectB
>>> before objectA) and it works around the problem, but it seems to me
>>> that when you have containment proxies, deleting the container
>>> should not alter the proxy's URI.
>> There are so few places that call InternalEObject.eSetProxyURI that I
>> doubt this could be happening.
>
> Doubt what could be happening? Something is definitely changing the
> Proxy URI.
When you said changing, I imagined that meaning it had value x at some
point and then value y later, where neither of those values was null.
Deleting a resource definitely turns all the objects into proxies and I
definitely expect that resource.delete will result in objects that don't
resolve at all anymore because the underlying resource where they live
is also deleted.
>
>>> Is this a bug or am I missing something?
>> I imagine that once you delete objectA you won't be able to resolve
>> any proxies that objectA references, containment or otherwise. So
>> best to ensure the proxies are resolved...
>
> Easier said than done. Again, I don't see why the proxy URI would
> change. If the proxy URI doesn't change, then the URI would still be
> resolvable and this problem would be avoided without having to do
> extra work.
Again this comment implies it has a good non null proxy URI that later
become a bad non null proxy URI. I can't begin to guess at how such a
thing is possible.
> After all, I don't necessarily know how many layers of proxies I
> need to walk through and resolve.
EcoreUtil.resolveAll will resolve all proxies that are resolvable.
>
> If there are too many layers, it came become problematic since the bug
> only shows up when there are unresolved proxies and then it becomes an
> order of operation problem. If the proxy URI doesn't become munged,
> then the order of operation no longer matters.
Are you doing anything to clean up references to the deleted objects?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Delete changes containment proxy values [message #546439 is a reply to message #546434] |
Mon, 12 July 2010 18:56 |
Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Hi Ed,
I do not think we are communicating very well. You've now said that what I'm observing is impossible.
>>> Stephen McCants wrote:
>>>> Hello,
>>>> I've found what I think is an EMF bug, but I could be wrong.
>>> Probably. :-P
>>>> I have containment proxies enabled and I have objectA in resource1
>>>> that has a containment reference to objectB that is in resource2. If
>>>> both of the objects are loaded and I delete objectA and then
>>>> objectB, things work correctly.
>>> As in delete command?
>>
>> resource.delete(null);
> That will turn all contained objects into proxies. I.e.,
> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
> where uri is the URI of the containing resource.
That is not the behavior I'm observing. In fact, if I resolve the proxies ahead of time, then
everything works correctly. They are not turned back into proxies. I suspect this is because I
have "containment proxies" enabled, so that EMF recognizes that these proxies may belong to another
resource and not the resource that was deleted (which is the case in my example).
>>
>>>> However, if objectA has an EProxy for objectB and I delete
>>>> objectA, then something changes/munges/breaks the proxy URI for
>>>> objectB.
>>> It changes from what to what?
>>
>> I'd have to rebreak my code to see exactly what it became. What it
>> was doing was not obvious to me, but it I think it was trying to make
>> objectB a proxy that pointed into the parent resource for resource1.
> I'd expect it to use resource B.
It does not.
>>
>>>> Then when I try to delete objectB, it fails because the URI is wrong.
>>
>>> Once objectA isn't contained by a resource set, proxies won't resolve
>>> anymore.
>>
>> Why not? Object B is a proxy to a different resource. That resource
>> has not been deleted.
> The resource set needs to be reachable from the object (i.e.,
> x.eResource() != null && x.eResource().getResourceSet() != null) for it
> to be able to resolve proxies.
Even when you are dealing with proxies that belong to a different resource than their containing
eObject?
In my case, there is another eObject that is the container for eObject A (call it eObject Z).
EObject Z belongs to resource Z. If I'm not mistaken, A.eResource() after A's resource has been
deleted will return resource Z. So, the resource set is still accessible.
>>
>>>> I looked for the code that is making the change, but was unable to
>>>> find it.
>>> Setting breakpoints you mean?
>>
>> Yes.
>>
>>>> If I'm careful, I can reverse the behaviour (delete objectB
>>>> before objectA) and it works around the problem, but it seems to me
>>>> that when you have containment proxies, deleting the container
>>>> should not alter the proxy's URI.
>>> There are so few places that call InternalEObject.eSetProxyURI that I
>>> doubt this could be happening.
>>
>> Doubt what could be happening? Something is definitely changing the
>> Proxy URI.
> When you said changing, I imagined that meaning it had value x at some
> point and then value y later, where neither of those values was null.
Correct. This is what I observed.
> Deleting a resource definitely turns all the objects into proxies and I
> definitely expect that resource.delete will result in objects that don't
> resolve at all anymore because the underlying resource where they live
> is also deleted.
This is not what I observed. But remember, my proxies do not belong to the deleted resource.
>>
>>>> Is this a bug or am I missing something?
>>> I imagine that once you delete objectA you won't be able to resolve
>>> any proxies that objectA references, containment or otherwise. So
>>> best to ensure the proxies are resolved...
>>
>> Easier said than done. Again, I don't see why the proxy URI would
>> change. If the proxy URI doesn't change, then the URI would still be
>> resolvable and this problem would be avoided without having to do
>> extra work.
> Again this comment implies it has a good non null proxy URI that later
> become a bad non null proxy URI. I can't begin to guess at how such a
> thing is possible.
Me neither, but I've watched it happen.
>> After all, I don't necessarily know how many layers of proxies I
>> need to walk through and resolve.
> EcoreUtil.resolveAll will resolve all proxies that are resolvable.
>>
>> If there are too many layers, it came become problematic since the bug
>> only shows up when there are unresolved proxies and then it becomes an
>> order of operation problem. If the proxy URI doesn't become munged,
>> then the order of operation no longer matters.
> Are you doing anything to clean up references to the deleted objects?
I'm not sure I understand that question. I am not knowingly changing the URIs inside the proxies
when I delete their containing eObject's resource.
|
|
|
| Re: Delete changes containment proxy values [message #546446 is a reply to message #546439] |
Mon, 12 July 2010 19:21 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stephen,
Comments below.
Stephen McCants wrote:
> Hi Ed,
> I do not think we are communicating very well. You've now said
> that what I'm observing is impossible.
It's not clear to me what you're observing. No doubt a test case is
worth a thousand newsgroup posts.
>
>>>> Stephen McCants wrote:
>>>>> Hello,
>>>>> I've found what I think is an EMF bug, but I could be wrong.
>>>> Probably. :-P
>>>>> I have containment proxies enabled and I have objectA in resource1
>>>>> that has a containment reference to objectB that is in resource2.
>>>>> If both of the objects are loaded and I delete objectA and then
>>>>> objectB, things work correctly.
>>>> As in delete command?
>>>
>>> resource.delete(null);
>> That will turn all contained objects into proxies. I.e.,
>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
>> where uri is the URI of the containing resource.
>
> That is not the behavior I'm observing.
You've stepped through the calls when you invoke resource.delete(null)?
I'd expect it to end up in ResourceImpl.doUnload which would call
unloaded for the whole tree of objects doing exactly what I described above.
> In fact, if I resolve the proxies ahead of time, then everything
> works correctly. They are not turned back into proxies.
What is resource.delete actually doing in this case?
> I suspect this is because I have "containment proxies" enabled, so
> that EMF recognizes that these proxies may belong to another resource
> and not the resource that was deleted (which is the case in my example).
>
>>>
>>>>> However, if objectA has an EProxy for objectB and I delete
>>>>> objectA, then something changes/munges/breaks the proxy URI for
>>>>> objectB.
>>>> It changes from what to what?
>>>
>>> I'd have to rebreak my code to see exactly what it became. What it
>>> was doing was not obvious to me, but it I think it was trying to
>>> make objectB a proxy that pointed into the parent resource for
>>> resource1.
>> I'd expect it to use resource B.
>
> It does not.
What does it use?
>
>>>
>>>>> Then when I try to delete objectB, it fails because the URI is wrong.
>>>
>>>> Once objectA isn't contained by a resource set, proxies won't
>>>> resolve anymore.
>>>
>>> Why not? Object B is a proxy to a different resource. That
>>> resource has not been deleted.
>> The resource set needs to be reachable from the object (i.e.,
>> x.eResource() != null && x.eResource().getResourceSet() != null) for
>> it to be able to resolve proxies.
>
> Even when you are dealing with proxies that belong to a different
> resource than their containing eObject?
Have a look at the logic followed by EcoreUtil.resolve(EObject, EObject).
>
> In my case, there is another eObject that is the container for eObject
> A (call it eObject Z). EObject Z belongs to resource Z. If I'm not
> mistaken, A.eResource() after A's resource has been deleted will
> return resource Z.
Notice that you've provided yet another new piece of information I
couldn't have known about before, I.e., Z and its resource. Also, here
you're talking about removing A's resource where up to now I would have
though you were deleting B's resource...
I would expect A itself to be turned into a proxy when its resource is
deleted. Is that happening? I'd also expect the underlying resource to
be removed from the workspace and for the A proxy to be unresolvable.
You might not notice that A is an unresolveable proxy because all of A's
features will remain populated; as such, you might be under the
impression that A has moved to be a child of the Z resource. If that's
what you want, you should remove A from A's resource and then delete the
empty resource that's left.
> So, the resource set is still accessible.
So it would appear, but how am I to know?
>
>>>
>>>>> I looked for the code that is making the change, but was unable to
>>>>> find it.
>>>> Setting breakpoints you mean?
>>>
>>> Yes.
>>>
>>>>> If I'm careful, I can reverse the behaviour (delete objectB
>>>>> before objectA) and it works around the problem, but it seems to
>>>>> me that when you have containment proxies, deleting the container
>>>>> should not alter the proxy's URI.
>>>> There are so few places that call InternalEObject.eSetProxyURI that
>>>> I doubt this could be happening.
>>>
>>> Doubt what could be happening? Something is definitely changing the
>>> Proxy URI.
>> When you said changing, I imagined that meaning it had value x at
>> some point and then value y later, where neither of those values was
>> null.
>
> Correct. This is what I observed.
The code is like this:
protected void unloaded(InternalEObject internalEObject)
{
// Ensure that an unresolved containment proxy's URI isn't reset.
//
if (!internalEObject.eIsProxy())
{
internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)));
}
internalEObject.eAdapters().clear();
}
which would appear to make it impossible for unloading to change the
proxy URI from one non-null value to another. What can I say?
>
>> Deleting a resource definitely turns all the objects into proxies and
>> I definitely expect that resource.delete will result in objects that
>> don't resolve at all anymore because the underlying resource where
>> they live is also deleted.
>
> This is not what I observed. But remember, my proxies do not belong
> to the deleted resource.
>
>>>
>>>>> Is this a bug or am I missing something?
>>>> I imagine that once you delete objectA you won't be able to resolve
>>>> any proxies that objectA references, containment or otherwise. So
>>>> best to ensure the proxies are resolved...
>>>
>>> Easier said than done. Again, I don't see why the proxy URI would
>>> change. If the proxy URI doesn't change, then the URI would still
>>> be resolvable and this problem would be avoided without having to do
>>> extra work.
>> Again this comment implies it has a good non null proxy URI that
>> later become a bad non null proxy URI. I can't begin to guess at how
>> such a thing is possible.
>
> Me neither, but I've watched it happen.
So you should be able to see on the stack what lead to such a
situation. I can only imagine.
>
>>> After all, I don't necessarily know how many layers of proxies I
>>> need to walk through and resolve.
>> EcoreUtil.resolveAll will resolve all proxies that are resolvable.
>>>
>>> If there are too many layers, it came become problematic since the
>>> bug only shows up when there are unresolved proxies and then it
>>> becomes an order of operation problem. If the proxy URI doesn't
>>> become munged, then the order of operation no longer matters.
>> Are you doing anything to clean up references to the deleted objects?
>
> I'm not sure I understand that question. I am not knowingly changing
> the URIs inside the proxies when I delete their containing eObject's
> resource.
You should expect that deleting a resource will require you to clean up
all references to the contained object. It doesn't sound like you're
doing that or even expecting to do that. Something is wrong with that
picture. It's starting to sound like you really want to clear your
resource before you delete it so that the objects themselves will end up
being contained in a different resource, rather than being deleted
(turned into proxies).
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Delete changes containment proxy values [message #546697 is a reply to message #546446] |
Tue, 13 July 2010 19:48 |
Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Hi Ed,
I think we have successfully failed to communicate enough that a test case is our only hope. It is
getting much too difficult to read the posts below, even though I think I see several places where
I've failed to convey what is happening.
I may try to put a test case together and see if I can demonstrate this problem in a neutral
environment.
--Stephen
Ed Merks wrote:
> Stephen,
>
> Comments below.
>
> Stephen McCants wrote:
>> Hi Ed,
>> I do not think we are communicating very well. You've now said
>> that what I'm observing is impossible.
> It's not clear to me what you're observing. No doubt a test case is
> worth a thousand newsgroup posts.
>>
>>>>> Stephen McCants wrote:
>>>>>> Hello,
>>>>>> I've found what I think is an EMF bug, but I could be wrong.
>>>>> Probably. :-P
>>>>>> I have containment proxies enabled and I have objectA in resource1
>>>>>> that has a containment reference to objectB that is in resource2.
>>>>>> If both of the objects are loaded and I delete objectA and then
>>>>>> objectB, things work correctly.
>>>>> As in delete command?
>>>>
>>>> resource.delete(null);
>>> That will turn all contained objects into proxies. I.e.,
>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
>>> where uri is the URI of the containing resource.
>>
>> That is not the behavior I'm observing.
> You've stepped through the calls when you invoke resource.delete(null)?
> I'd expect it to end up in ResourceImpl.doUnload which would call
> unloaded for the whole tree of objects doing exactly what I described
> above.
>> In fact, if I resolve the proxies ahead of time, then everything
>> works correctly. They are not turned back into proxies.
> What is resource.delete actually doing in this case?
>> I suspect this is because I have "containment proxies" enabled, so
>> that EMF recognizes that these proxies may belong to another resource
>> and not the resource that was deleted (which is the case in my example).
>>
>>>>
>>>>>> However, if objectA has an EProxy for objectB and I delete
>>>>>> objectA, then something changes/munges/breaks the proxy URI for
>>>>>> objectB.
>>>>> It changes from what to what?
>>>>
>>>> I'd have to rebreak my code to see exactly what it became. What it
>>>> was doing was not obvious to me, but it I think it was trying to
>>>> make objectB a proxy that pointed into the parent resource for
>>>> resource1.
>>> I'd expect it to use resource B.
>>
>> It does not.
> What does it use?
>>
>>>>
>>>>>> Then when I try to delete objectB, it fails because the URI is wrong.
>>>>
>>>>> Once objectA isn't contained by a resource set, proxies won't
>>>>> resolve anymore.
>>>>
>>>> Why not? Object B is a proxy to a different resource. That
>>>> resource has not been deleted.
>>> The resource set needs to be reachable from the object (i.e.,
>>> x.eResource() != null && x.eResource().getResourceSet() != null) for
>>> it to be able to resolve proxies.
>>
>> Even when you are dealing with proxies that belong to a different
>> resource than their containing eObject?
> Have a look at the logic followed by EcoreUtil.resolve(EObject, EObject).
>>
>> In my case, there is another eObject that is the container for eObject
>> A (call it eObject Z). EObject Z belongs to resource Z. If I'm not
>> mistaken, A.eResource() after A's resource has been deleted will
>> return resource Z.
> Notice that you've provided yet another new piece of information I
> couldn't have known about before, I.e., Z and its resource. Also, here
> you're talking about removing A's resource where up to now I would have
> though you were deleting B's resource...
>
> I would expect A itself to be turned into a proxy when its resource is
> deleted. Is that happening? I'd also expect the underlying resource to
> be removed from the workspace and for the A proxy to be unresolvable.
> You might not notice that A is an unresolveable proxy because all of A's
> features will remain populated; as such, you might be under the
> impression that A has moved to be a child of the Z resource. If that's
> what you want, you should remove A from A's resource and then delete the
> empty resource that's left.
>> So, the resource set is still accessible.
> So it would appear, but how am I to know?
>>
>>>>
>>>>>> I looked for the code that is making the change, but was unable to
>>>>>> find it.
>>>>> Setting breakpoints you mean?
>>>>
>>>> Yes.
>>>>
>>>>>> If I'm careful, I can reverse the behaviour (delete objectB
>>>>>> before objectA) and it works around the problem, but it seems to
>>>>>> me that when you have containment proxies, deleting the container
>>>>>> should not alter the proxy's URI.
>>>>> There are so few places that call InternalEObject.eSetProxyURI that
>>>>> I doubt this could be happening.
>>>>
>>>> Doubt what could be happening? Something is definitely changing the
>>>> Proxy URI.
>>> When you said changing, I imagined that meaning it had value x at
>>> some point and then value y later, where neither of those values was
>>> null.
>>
>> Correct. This is what I observed.
> The code is like this:
>
> protected void unloaded(InternalEObject internalEObject)
> {
> // Ensure that an unresolved containment proxy's URI isn't reset.
> //
> if (!internalEObject.eIsProxy())
> {
>
> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)));
>
> }
> internalEObject.eAdapters().clear();
> }
>
> which would appear to make it impossible for unloading to change the
> proxy URI from one non-null value to another. What can I say?
>>
>>> Deleting a resource definitely turns all the objects into proxies and
>>> I definitely expect that resource.delete will result in objects that
>>> don't resolve at all anymore because the underlying resource where
>>> they live is also deleted.
>>
>> This is not what I observed. But remember, my proxies do not belong
>> to the deleted resource.
>>
>>>>
>>>>>> Is this a bug or am I missing something?
>>>>> I imagine that once you delete objectA you won't be able to resolve
>>>>> any proxies that objectA references, containment or otherwise. So
>>>>> best to ensure the proxies are resolved...
>>>>
>>>> Easier said than done. Again, I don't see why the proxy URI would
>>>> change. If the proxy URI doesn't change, then the URI would still
>>>> be resolvable and this problem would be avoided without having to do
>>>> extra work.
>>> Again this comment implies it has a good non null proxy URI that
>>> later become a bad non null proxy URI. I can't begin to guess at how
>>> such a thing is possible.
>>
>> Me neither, but I've watched it happen.
> So you should be able to see on the stack what lead to such a
> situation. I can only imagine.
>>
>>>> After all, I don't necessarily know how many layers of proxies I
>>>> need to walk through and resolve.
>>> EcoreUtil.resolveAll will resolve all proxies that are resolvable.
>>>>
>>>> If there are too many layers, it came become problematic since the
>>>> bug only shows up when there are unresolved proxies and then it
>>>> becomes an order of operation problem. If the proxy URI doesn't
>>>> become munged, then the order of operation no longer matters.
>>> Are you doing anything to clean up references to the deleted objects?
>>
>> I'm not sure I understand that question. I am not knowingly changing
>> the URIs inside the proxies when I delete their containing eObject's
>> resource.
> You should expect that deleting a resource will require you to clean up
> all references to the contained object. It doesn't sound like you're
> doing that or even expecting to do that. Something is wrong with that
> picture. It's starting to sound like you really want to clear your
> resource before you delete it so that the objects themselves will end up
> being contained in a different resource, rather than being deleted
> (turned into proxies).
|
|
|
| Re: Delete changes containment proxy values [message #550308 is a reply to message #546697] |
Thu, 29 July 2010 20:27 |
Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
I've decided not to bother with a test case, although I believe the problem is very real.
--Stephen
Stephen McCants wrote:
> Hi Ed,
> I think we have successfully failed to communicate enough that a
> test case is our only hope. It is getting much too difficult to read
> the posts below, even though I think I see several places where I've
> failed to convey what is happening.
> I may try to put a test case together and see if I can demonstrate
> this problem in a neutral environment.
>
> --Stephen
>
> Ed Merks wrote:
>> Stephen,
>>
>> Comments below.
>>
>> Stephen McCants wrote:
>>> Hi Ed,
>>> I do not think we are communicating very well. You've now said
>>> that what I'm observing is impossible.
>> It's not clear to me what you're observing. No doubt a test case is
>> worth a thousand newsgroup posts.
>>>
>>>>>> Stephen McCants wrote:
>>>>>>> Hello,
>>>>>>> I've found what I think is an EMF bug, but I could be wrong.
>>>>>> Probably. :-P
>>>>>>> I have containment proxies enabled and I have objectA in
>>>>>>> resource1 that has a containment reference to objectB that is in
>>>>>>> resource2. If both of the objects are loaded and I delete objectA
>>>>>>> and then objectB, things work correctly.
>>>>>> As in delete command?
>>>>>
>>>>> resource.delete(null);
>>>> That will turn all contained objects into proxies. I.e.,
>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
>>>> where uri is the URI of the containing resource.
>>>
>>> That is not the behavior I'm observing.
>> You've stepped through the calls when you invoke
>> resource.delete(null)? I'd expect it to end up in
>> ResourceImpl.doUnload which would call unloaded for the whole tree of
>> objects doing exactly what I described above.
>>> In fact, if I resolve the proxies ahead of time, then everything
>>> works correctly. They are not turned back into proxies.
>> What is resource.delete actually doing in this case?
>>> I suspect this is because I have "containment proxies" enabled, so
>>> that EMF recognizes that these proxies may belong to another resource
>>> and not the resource that was deleted (which is the case in my example).
>>>
>>>>>
>>>>>>> However, if objectA has an EProxy for objectB and I delete
>>>>>>> objectA, then something changes/munges/breaks the proxy URI for
>>>>>>> objectB.
>>>>>> It changes from what to what?
>>>>>
>>>>> I'd have to rebreak my code to see exactly what it became. What it
>>>>> was doing was not obvious to me, but it I think it was trying to
>>>>> make objectB a proxy that pointed into the parent resource for
>>>>> resource1.
>>>> I'd expect it to use resource B.
>>>
>>> It does not.
>> What does it use?
>>>
>>>>>
>>>>>>> Then when I try to delete objectB, it fails because the URI is
>>>>>>> wrong.
>>>>>
>>>>>> Once objectA isn't contained by a resource set, proxies won't
>>>>>> resolve anymore.
>>>>>
>>>>> Why not? Object B is a proxy to a different resource. That
>>>>> resource has not been deleted.
>>>> The resource set needs to be reachable from the object (i.e.,
>>>> x.eResource() != null && x.eResource().getResourceSet() != null) for
>>>> it to be able to resolve proxies.
>>>
>>> Even when you are dealing with proxies that belong to a different
>>> resource than their containing eObject?
>> Have a look at the logic followed by EcoreUtil.resolve(EObject, EObject).
>>>
>>> In my case, there is another eObject that is the container for
>>> eObject A (call it eObject Z). EObject Z belongs to resource Z. If
>>> I'm not mistaken, A.eResource() after A's resource has been deleted
>>> will return resource Z.
>> Notice that you've provided yet another new piece of information I
>> couldn't have known about before, I.e., Z and its resource. Also,
>> here you're talking about removing A's resource where up to now I
>> would have though you were deleting B's resource...
>>
>> I would expect A itself to be turned into a proxy when its resource is
>> deleted. Is that happening? I'd also expect the underlying resource
>> to be removed from the workspace and for the A proxy to be
>> unresolvable. You might not notice that A is an unresolveable proxy
>> because all of A's features will remain populated; as such, you might
>> be under the impression that A has moved to be a child of the Z
>> resource. If that's what you want, you should remove A from A's
>> resource and then delete the empty resource that's left.
>>> So, the resource set is still accessible.
>> So it would appear, but how am I to know?
>>>
>>>>>
>>>>>>> I looked for the code that is making the change, but was unable
>>>>>>> to find it.
>>>>>> Setting breakpoints you mean?
>>>>>
>>>>> Yes.
>>>>>
>>>>>>> If I'm careful, I can reverse the behaviour (delete objectB
>>>>>>> before objectA) and it works around the problem, but it seems to
>>>>>>> me that when you have containment proxies, deleting the container
>>>>>>> should not alter the proxy's URI.
>>>>>> There are so few places that call InternalEObject.eSetProxyURI
>>>>>> that I doubt this could be happening.
>>>>>
>>>>> Doubt what could be happening? Something is definitely changing
>>>>> the Proxy URI.
>>>> When you said changing, I imagined that meaning it had value x at
>>>> some point and then value y later, where neither of those values was
>>>> null.
>>>
>>> Correct. This is what I observed.
>> The code is like this:
>>
>> protected void unloaded(InternalEObject internalEObject)
>> {
>> // Ensure that an unresolved containment proxy's URI isn't reset.
>> //
>> if (!internalEObject.eIsProxy())
>> {
>>
>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)));
>>
>> }
>> internalEObject.eAdapters().clear();
>> }
>>
>> which would appear to make it impossible for unloading to change the
>> proxy URI from one non-null value to another. What can I say?
>>>
>>>> Deleting a resource definitely turns all the objects into proxies
>>>> and I definitely expect that resource.delete will result in objects
>>>> that don't resolve at all anymore because the underlying resource
>>>> where they live is also deleted.
>>>
>>> This is not what I observed. But remember, my proxies do not belong
>>> to the deleted resource.
>>>
>>>>>
>>>>>>> Is this a bug or am I missing something?
>>>>>> I imagine that once you delete objectA you won't be able to
>>>>>> resolve any proxies that objectA references, containment or
>>>>>> otherwise. So best to ensure the proxies are resolved...
>>>>>
>>>>> Easier said than done. Again, I don't see why the proxy URI would
>>>>> change. If the proxy URI doesn't change, then the URI would still
>>>>> be resolvable and this problem would be avoided without having to
>>>>> do extra work.
>>>> Again this comment implies it has a good non null proxy URI that
>>>> later become a bad non null proxy URI. I can't begin to guess at
>>>> how such a thing is possible.
>>>
>>> Me neither, but I've watched it happen.
>> So you should be able to see on the stack what lead to such a
>> situation. I can only imagine.
>>>
>>>>> After all, I don't necessarily know how many layers of proxies I
>>>>> need to walk through and resolve.
>>>> EcoreUtil.resolveAll will resolve all proxies that are resolvable.
>>>>>
>>>>> If there are too many layers, it came become problematic since the
>>>>> bug only shows up when there are unresolved proxies and then it
>>>>> becomes an order of operation problem. If the proxy URI doesn't
>>>>> become munged, then the order of operation no longer matters.
>>>> Are you doing anything to clean up references to the deleted objects?
>>>
>>> I'm not sure I understand that question. I am not knowingly changing
>>> the URIs inside the proxies when I delete their containing eObject's
>>> resource.
>> You should expect that deleting a resource will require you to clean
>> up all references to the contained object. It doesn't sound like
>> you're doing that or even expecting to do that. Something is wrong
>> with that picture. It's starting to sound like you really want to
>> clear your resource before you delete it so that the objects
>> themselves will end up being contained in a different resource, rather
>> than being deleted (turned into proxies).
|
|
|
| Re: Delete changes containment proxy values [message #550328 is a reply to message #550308] |
Thu, 29 July 2010 22:33 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stephen,
That's unfortunate. :-( Unreported problems definitely don't get fixed.
Stephen McCants wrote:
> I've decided not to bother with a test case, although I believe the
> problem is very real.
> --Stephen
>
> Stephen McCants wrote:
>> Hi Ed,
>> I think we have successfully failed to communicate enough that a
>> test case is our only hope. It is getting much too difficult to read
>> the posts below, even though I think I see several places where I've
>> failed to convey what is happening.
>> I may try to put a test case together and see if I can
>> demonstrate this problem in a neutral environment.
>>
>> --Stephen
>>
>> Ed Merks wrote:
>>> Stephen,
>>>
>>> Comments below.
>>>
>>> Stephen McCants wrote:
>>>> Hi Ed,
>>>> I do not think we are communicating very well. You've now said
>>>> that what I'm observing is impossible.
>>> It's not clear to me what you're observing. No doubt a test case
>>> is worth a thousand newsgroup posts.
>>>>
>>>>>>> Stephen McCants wrote:
>>>>>>>> Hello,
>>>>>>>> I've found what I think is an EMF bug, but I could be wrong.
>>>>>>> Probably. :-P
>>>>>>>> I have containment proxies enabled and I have objectA in
>>>>>>>> resource1 that has a containment reference to objectB that is
>>>>>>>> in resource2. If both of the objects are loaded and I delete
>>>>>>>> objectA and then objectB, things work correctly.
>>>>>>> As in delete command?
>>>>>>
>>>>>> resource.delete(null);
>>>>> That will turn all contained objects into proxies. I.e.,
>>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
>>>>> where uri is the URI of the containing resource.
>>>>
>>>> That is not the behavior I'm observing.
>>> You've stepped through the calls when you invoke
>>> resource.delete(null)? I'd expect it to end up in
>>> ResourceImpl.doUnload which would call unloaded for the whole tree
>>> of objects doing exactly what I described above.
>>>> In fact, if I resolve the proxies ahead of time, then everything
>>>> works correctly. They are not turned back into proxies.
>>> What is resource.delete actually doing in this case?
>>>> I suspect this is because I have "containment proxies" enabled, so
>>>> that EMF recognizes that these proxies may belong to another
>>>> resource and not the resource that was deleted (which is the case
>>>> in my example).
>>>>
>>>>>>
>>>>>>>> However, if objectA has an EProxy for objectB and I delete
>>>>>>>> objectA, then something changes/munges/breaks the proxy URI for
>>>>>>>> objectB.
>>>>>>> It changes from what to what?
>>>>>>
>>>>>> I'd have to rebreak my code to see exactly what it became. What
>>>>>> it was doing was not obvious to me, but it I think it was trying
>>>>>> to make objectB a proxy that pointed into the parent resource for
>>>>>> resource1.
>>>>> I'd expect it to use resource B.
>>>>
>>>> It does not.
>>> What does it use?
>>>>
>>>>>>
>>>>>>>> Then when I try to delete objectB, it fails because the URI is
>>>>>>>> wrong.
>>>>>>
>>>>>>> Once objectA isn't contained by a resource set, proxies won't
>>>>>>> resolve anymore.
>>>>>>
>>>>>> Why not? Object B is a proxy to a different resource. That
>>>>>> resource has not been deleted.
>>>>> The resource set needs to be reachable from the object (i.e.,
>>>>> x.eResource() != null && x.eResource().getResourceSet() != null)
>>>>> for it to be able to resolve proxies.
>>>>
>>>> Even when you are dealing with proxies that belong to a different
>>>> resource than their containing eObject?
>>> Have a look at the logic followed by EcoreUtil.resolve(EObject,
>>> EObject).
>>>>
>>>> In my case, there is another eObject that is the container for
>>>> eObject A (call it eObject Z). EObject Z belongs to resource Z. If
>>>> I'm not mistaken, A.eResource() after A's resource has been deleted
>>>> will return resource Z.
>>> Notice that you've provided yet another new piece of information I
>>> couldn't have known about before, I.e., Z and its resource. Also,
>>> here you're talking about removing A's resource where up to now I
>>> would have though you were deleting B's resource...
>>>
>>> I would expect A itself to be turned into a proxy when its resource
>>> is deleted. Is that happening? I'd also expect the underlying
>>> resource to be removed from the workspace and for the A proxy to be
>>> unresolvable. You might not notice that A is an unresolveable proxy
>>> because all of A's features will remain populated; as such, you
>>> might be under the impression that A has moved to be a child of the
>>> Z resource. If that's what you want, you should remove A from A's
>>> resource and then delete the empty resource that's left.
>>>> So, the resource set is still accessible.
>>> So it would appear, but how am I to know?
>>>>
>>>>>>
>>>>>>>> I looked for the code that is making the change, but was unable
>>>>>>>> to find it.
>>>>>>> Setting breakpoints you mean?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>>> If I'm careful, I can reverse the behaviour (delete objectB
>>>>>>>> before objectA) and it works around the problem, but it seems
>>>>>>>> to me that when you have containment proxies, deleting the
>>>>>>>> container should not alter the proxy's URI.
>>>>>>> There are so few places that call InternalEObject.eSetProxyURI
>>>>>>> that I doubt this could be happening.
>>>>>>
>>>>>> Doubt what could be happening? Something is definitely changing
>>>>>> the Proxy URI.
>>>>> When you said changing, I imagined that meaning it had value x at
>>>>> some point and then value y later, where neither of those values
>>>>> was null.
>>>>
>>>> Correct. This is what I observed.
>>> The code is like this:
>>>
>>> protected void unloaded(InternalEObject internalEObject)
>>> {
>>> // Ensure that an unresolved containment proxy's URI isn't reset.
>>> //
>>> if (!internalEObject.eIsProxy())
>>> {
>>>
>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)));
>>>
>>> }
>>> internalEObject.eAdapters().clear();
>>> }
>>>
>>> which would appear to make it impossible for unloading to change the
>>> proxy URI from one non-null value to another. What can I say?
>>>>
>>>>> Deleting a resource definitely turns all the objects into proxies
>>>>> and I definitely expect that resource.delete will result in
>>>>> objects that don't resolve at all anymore because the underlying
>>>>> resource where they live is also deleted.
>>>>
>>>> This is not what I observed. But remember, my proxies do not
>>>> belong to the deleted resource.
>>>>
>>>>>>
>>>>>>>> Is this a bug or am I missing something?
>>>>>>> I imagine that once you delete objectA you won't be able to
>>>>>>> resolve any proxies that objectA references, containment or
>>>>>>> otherwise. So best to ensure the proxies are resolved...
>>>>>>
>>>>>> Easier said than done. Again, I don't see why the proxy URI
>>>>>> would change. If the proxy URI doesn't change, then the URI
>>>>>> would still be resolvable and this problem would be avoided
>>>>>> without having to do extra work.
>>>>> Again this comment implies it has a good non null proxy URI that
>>>>> later become a bad non null proxy URI. I can't begin to guess at
>>>>> how such a thing is possible.
>>>>
>>>> Me neither, but I've watched it happen.
>>> So you should be able to see on the stack what lead to such a
>>> situation. I can only imagine.
>>>>
>>>>>> After all, I don't necessarily know how many layers of proxies
>>>>>> I need to walk through and resolve.
>>>>> EcoreUtil.resolveAll will resolve all proxies that are resolvable.
>>>>>>
>>>>>> If there are too many layers, it came become problematic since
>>>>>> the bug only shows up when there are unresolved proxies and then
>>>>>> it becomes an order of operation problem. If the proxy URI
>>>>>> doesn't become munged, then the order of operation no longer
>>>>>> matters.
>>>>> Are you doing anything to clean up references to the deleted objects?
>>>>
>>>> I'm not sure I understand that question. I am not knowingly
>>>> changing the URIs inside the proxies when I delete their containing
>>>> eObject's resource.
>>> You should expect that deleting a resource will require you to clean
>>> up all references to the contained object. It doesn't sound like
>>> you're doing that or even expecting to do that. Something is wrong
>>> with that picture. It's starting to sound like you really want to
>>> clear your resource before you delete it so that the objects
>>> themselves will end up being contained in a different resource,
>>> rather than being deleted (turned into proxies).
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Delete changes containment proxy values [message #550547 is a reply to message #550328] |
Fri, 30 July 2010 18:25 |
Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Ed,
In my experience, reported problems are only rarely fixed.
--Stephen
Ed Merks wrote:
> Stephen,
>
> That's unfortunate. :-( Unreported problems definitely don't get fixed.
>
>
> Stephen McCants wrote:
>> I've decided not to bother with a test case, although I believe the
>> problem is very real.
>> --Stephen
>>
>> Stephen McCants wrote:
>>> Hi Ed,
>>> I think we have successfully failed to communicate enough that a
>>> test case is our only hope. It is getting much too difficult to read
>>> the posts below, even though I think I see several places where I've
>>> failed to convey what is happening.
>>> I may try to put a test case together and see if I can
>>> demonstrate this problem in a neutral environment.
>>>
>>> --Stephen
>>>
>>> Ed Merks wrote:
>>>> Stephen,
>>>>
>>>> Comments below.
>>>>
>>>> Stephen McCants wrote:
>>>>> Hi Ed,
>>>>> I do not think we are communicating very well. You've now said
>>>>> that what I'm observing is impossible.
>>>> It's not clear to me what you're observing. No doubt a test case
>>>> is worth a thousand newsgroup posts.
>>>>>
>>>>>>>> Stephen McCants wrote:
>>>>>>>>> Hello,
>>>>>>>>> I've found what I think is an EMF bug, but I could be wrong.
>>>>>>>> Probably. :-P
>>>>>>>>> I have containment proxies enabled and I have objectA in
>>>>>>>>> resource1 that has a containment reference to objectB that is
>>>>>>>>> in resource2. If both of the objects are loaded and I delete
>>>>>>>>> objectA and then objectB, things work correctly.
>>>>>>>> As in delete command?
>>>>>>>
>>>>>>> resource.delete(null);
>>>>>> That will turn all contained objects into proxies. I.e.,
>>>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
>>>>>> where uri is the URI of the containing resource.
>>>>>
>>>>> That is not the behavior I'm observing.
>>>> You've stepped through the calls when you invoke
>>>> resource.delete(null)? I'd expect it to end up in
>>>> ResourceImpl.doUnload which would call unloaded for the whole tree
>>>> of objects doing exactly what I described above.
>>>>> In fact, if I resolve the proxies ahead of time, then everything
>>>>> works correctly. They are not turned back into proxies.
>>>> What is resource.delete actually doing in this case?
>>>>> I suspect this is because I have "containment proxies" enabled, so
>>>>> that EMF recognizes that these proxies may belong to another
>>>>> resource and not the resource that was deleted (which is the case
>>>>> in my example).
>>>>>
>>>>>>>
>>>>>>>>> However, if objectA has an EProxy for objectB and I delete
>>>>>>>>> objectA, then something changes/munges/breaks the proxy URI for
>>>>>>>>> objectB.
>>>>>>>> It changes from what to what?
>>>>>>>
>>>>>>> I'd have to rebreak my code to see exactly what it became. What
>>>>>>> it was doing was not obvious to me, but it I think it was trying
>>>>>>> to make objectB a proxy that pointed into the parent resource for
>>>>>>> resource1.
>>>>>> I'd expect it to use resource B.
>>>>>
>>>>> It does not.
>>>> What does it use?
>>>>>
>>>>>>>
>>>>>>>>> Then when I try to delete objectB, it fails because the URI is
>>>>>>>>> wrong.
>>>>>>>
>>>>>>>> Once objectA isn't contained by a resource set, proxies won't
>>>>>>>> resolve anymore.
>>>>>>>
>>>>>>> Why not? Object B is a proxy to a different resource. That
>>>>>>> resource has not been deleted.
>>>>>> The resource set needs to be reachable from the object (i.e.,
>>>>>> x.eResource() != null && x.eResource().getResourceSet() != null)
>>>>>> for it to be able to resolve proxies.
>>>>>
>>>>> Even when you are dealing with proxies that belong to a different
>>>>> resource than their containing eObject?
>>>> Have a look at the logic followed by EcoreUtil.resolve(EObject,
>>>> EObject).
>>>>>
>>>>> In my case, there is another eObject that is the container for
>>>>> eObject A (call it eObject Z). EObject Z belongs to resource Z. If
>>>>> I'm not mistaken, A.eResource() after A's resource has been deleted
>>>>> will return resource Z.
>>>> Notice that you've provided yet another new piece of information I
>>>> couldn't have known about before, I.e., Z and its resource. Also,
>>>> here you're talking about removing A's resource where up to now I
>>>> would have though you were deleting B's resource...
>>>>
>>>> I would expect A itself to be turned into a proxy when its resource
>>>> is deleted. Is that happening? I'd also expect the underlying
>>>> resource to be removed from the workspace and for the A proxy to be
>>>> unresolvable. You might not notice that A is an unresolveable proxy
>>>> because all of A's features will remain populated; as such, you
>>>> might be under the impression that A has moved to be a child of the
>>>> Z resource. If that's what you want, you should remove A from A's
>>>> resource and then delete the empty resource that's left.
>>>>> So, the resource set is still accessible.
>>>> So it would appear, but how am I to know?
>>>>>
>>>>>>>
>>>>>>>>> I looked for the code that is making the change, but was unable
>>>>>>>>> to find it.
>>>>>>>> Setting breakpoints you mean?
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>>>> If I'm careful, I can reverse the behaviour (delete objectB
>>>>>>>>> before objectA) and it works around the problem, but it seems
>>>>>>>>> to me that when you have containment proxies, deleting the
>>>>>>>>> container should not alter the proxy's URI.
>>>>>>>> There are so few places that call InternalEObject.eSetProxyURI
>>>>>>>> that I doubt this could be happening.
>>>>>>>
>>>>>>> Doubt what could be happening? Something is definitely changing
>>>>>>> the Proxy URI.
>>>>>> When you said changing, I imagined that meaning it had value x at
>>>>>> some point and then value y later, where neither of those values
>>>>>> was null.
>>>>>
>>>>> Correct. This is what I observed.
>>>> The code is like this:
>>>>
>>>> protected void unloaded(InternalEObject internalEObject)
>>>> {
>>>> // Ensure that an unresolved containment proxy's URI isn't reset.
>>>> //
>>>> if (!internalEObject.eIsProxy())
>>>> {
>>>>
>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)));
>>>>
>>>> }
>>>> internalEObject.eAdapters().clear();
>>>> }
>>>>
>>>> which would appear to make it impossible for unloading to change the
>>>> proxy URI from one non-null value to another. What can I say?
>>>>>
>>>>>> Deleting a resource definitely turns all the objects into proxies
>>>>>> and I definitely expect that resource.delete will result in
>>>>>> objects that don't resolve at all anymore because the underlying
>>>>>> resource where they live is also deleted.
>>>>>
>>>>> This is not what I observed. But remember, my proxies do not
>>>>> belong to the deleted resource.
>>>>>
>>>>>>>
>>>>>>>>> Is this a bug or am I missing something?
>>>>>>>> I imagine that once you delete objectA you won't be able to
>>>>>>>> resolve any proxies that objectA references, containment or
>>>>>>>> otherwise. So best to ensure the proxies are resolved...
>>>>>>>
>>>>>>> Easier said than done. Again, I don't see why the proxy URI
>>>>>>> would change. If the proxy URI doesn't change, then the URI
>>>>>>> would still be resolvable and this problem would be avoided
>>>>>>> without having to do extra work.
>>>>>> Again this comment implies it has a good non null proxy URI that
>>>>>> later become a bad non null proxy URI. I can't begin to guess at
>>>>>> how such a thing is possible.
>>>>>
>>>>> Me neither, but I've watched it happen.
>>>> So you should be able to see on the stack what lead to such a
>>>> situation. I can only imagine.
>>>>>
>>>>>>> After all, I don't necessarily know how many layers of proxies
>>>>>>> I need to walk through and resolve.
>>>>>> EcoreUtil.resolveAll will resolve all proxies that are resolvable.
>>>>>>>
>>>>>>> If there are too many layers, it came become problematic since
>>>>>>> the bug only shows up when there are unresolved proxies and then
>>>>>>> it becomes an order of operation problem. If the proxy URI
>>>>>>> doesn't become munged, then the order of operation no longer
>>>>>>> matters.
>>>>>> Are you doing anything to clean up references to the deleted objects?
>>>>>
>>>>> I'm not sure I understand that question. I am not knowingly
>>>>> changing the URIs inside the proxies when I delete their containing
>>>>> eObject's resource.
>>>> You should expect that deleting a resource will require you to clean
>>>> up all references to the contained object. It doesn't sound like
>>>> you're doing that or even expecting to do that. Something is wrong
>>>> with that picture. It's starting to sound like you really want to
>>>> clear your resource before you delete it so that the objects
>>>> themselves will end up being contained in a different resource,
>>>> rather than being deleted (turned into proxies).
|
|
|
| Re: Delete changes containment proxy values [message #550585 is a reply to message #550547] |
Fri, 30 July 2010 22:32 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stephen,
You have one reported problem in EMF core. When asked for a test case,
you didn't provide one. How should I interpret that fact? I read it
as, "this problem isn't worth spending the time to create a test case"
which makes me wonder, "is it worth spending the time to investigate?"
Given that there is little value in defining a container reference for a
map entry---it doesn't even have any public API---it simply doesn't
factor high in the list of things on which to spend time.
Stephen McCants wrote:
> Ed,
> In my experience, reported problems are only rarely fixed.
> --Stephen
>
> Ed Merks wrote:
>> Stephen,
>>
>> That's unfortunate. :-( Unreported problems definitely don't get fixed.
>>
>>
>> Stephen McCants wrote:
>>> I've decided not to bother with a test case, although I believe the
>>> problem is very real.
>>> --Stephen
>>>
>>> Stephen McCants wrote:
>>>> Hi Ed,
>>>> I think we have successfully failed to communicate enough that
>>>> a test case is our only hope. It is getting much too difficult to
>>>> read the posts below, even though I think I see several places
>>>> where I've failed to convey what is happening.
>>>> I may try to put a test case together and see if I can
>>>> demonstrate this problem in a neutral environment.
>>>>
>>>> --Stephen
>>>>
>>>> Ed Merks wrote:
>>>>> Stephen,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Stephen McCants wrote:
>>>>>> Hi Ed,
>>>>>> I do not think we are communicating very well. You've now
>>>>>> said that what I'm observing is impossible.
>>>>> It's not clear to me what you're observing. No doubt a test case
>>>>> is worth a thousand newsgroup posts.
>>>>>>
>>>>>>>>> Stephen McCants wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> I've found what I think is an EMF bug, but I could be
>>>>>>>>>> wrong.
>>>>>>>>> Probably. :-P
>>>>>>>>>> I have containment proxies enabled and I have objectA in
>>>>>>>>>> resource1 that has a containment reference to objectB that is
>>>>>>>>>> in resource2. If both of the objects are loaded and I delete
>>>>>>>>>> objectA and then objectB, things work correctly.
>>>>>>>>> As in delete command?
>>>>>>>>
>>>>>>>> resource.delete(null);
>>>>>>> That will turn all contained objects into proxies. I.e.,
>>>>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
>>>>>>> where uri is the URI of the containing resource.
>>>>>>
>>>>>> That is not the behavior I'm observing.
>>>>> You've stepped through the calls when you invoke
>>>>> resource.delete(null)? I'd expect it to end up in
>>>>> ResourceImpl.doUnload which would call unloaded for the whole tree
>>>>> of objects doing exactly what I described above.
>>>>>> In fact, if I resolve the proxies ahead of time, then
>>>>>> everything works correctly. They are not turned back into proxies.
>>>>> What is resource.delete actually doing in this case?
>>>>>> I suspect this is because I have "containment proxies" enabled,
>>>>>> so that EMF recognizes that these proxies may belong to another
>>>>>> resource and not the resource that was deleted (which is the case
>>>>>> in my example).
>>>>>>
>>>>>>>>
>>>>>>>>>> However, if objectA has an EProxy for objectB and I
>>>>>>>>>> delete objectA, then something changes/munges/breaks the
>>>>>>>>>> proxy URI for objectB.
>>>>>>>>> It changes from what to what?
>>>>>>>>
>>>>>>>> I'd have to rebreak my code to see exactly what it became.
>>>>>>>> What it was doing was not obvious to me, but it I think it was
>>>>>>>> trying to make objectB a proxy that pointed into the parent
>>>>>>>> resource for resource1.
>>>>>>> I'd expect it to use resource B.
>>>>>>
>>>>>> It does not.
>>>>> What does it use?
>>>>>>
>>>>>>>>
>>>>>>>>>> Then when I try to delete objectB, it fails because the URI
>>>>>>>>>> is wrong.
>>>>>>>>
>>>>>>>>> Once objectA isn't contained by a resource set, proxies won't
>>>>>>>>> resolve anymore.
>>>>>>>>
>>>>>>>> Why not? Object B is a proxy to a different resource. That
>>>>>>>> resource has not been deleted.
>>>>>>> The resource set needs to be reachable from the object (i.e.,
>>>>>>> x.eResource() != null && x.eResource().getResourceSet() != null)
>>>>>>> for it to be able to resolve proxies.
>>>>>>
>>>>>> Even when you are dealing with proxies that belong to a different
>>>>>> resource than their containing eObject?
>>>>> Have a look at the logic followed by EcoreUtil.resolve(EObject,
>>>>> EObject).
>>>>>>
>>>>>> In my case, there is another eObject that is the container for
>>>>>> eObject A (call it eObject Z). EObject Z belongs to resource Z.
>>>>>> If I'm not mistaken, A.eResource() after A's resource has been
>>>>>> deleted will return resource Z.
>>>>> Notice that you've provided yet another new piece of information I
>>>>> couldn't have known about before, I.e., Z and its resource. Also,
>>>>> here you're talking about removing A's resource where up to now I
>>>>> would have though you were deleting B's resource...
>>>>>
>>>>> I would expect A itself to be turned into a proxy when its
>>>>> resource is deleted. Is that happening? I'd also expect the
>>>>> underlying resource to be removed from the workspace and for the A
>>>>> proxy to be unresolvable. You might not notice that A is an
>>>>> unresolveable proxy because all of A's features will remain
>>>>> populated; as such, you might be under the impression that A has
>>>>> moved to be a child of the Z resource. If that's what you want,
>>>>> you should remove A from A's resource and then delete the empty
>>>>> resource that's left.
>>>>>> So, the resource set is still accessible.
>>>>> So it would appear, but how am I to know?
>>>>>>
>>>>>>>>
>>>>>>>>>> I looked for the code that is making the change, but was
>>>>>>>>>> unable to find it.
>>>>>>>>> Setting breakpoints you mean?
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>>>> If I'm careful, I can reverse the behaviour (delete
>>>>>>>>>> objectB before objectA) and it works around the problem, but
>>>>>>>>>> it seems to me that when you have containment proxies,
>>>>>>>>>> deleting the container should not alter the proxy's URI.
>>>>>>>>> There are so few places that call InternalEObject.eSetProxyURI
>>>>>>>>> that I doubt this could be happening.
>>>>>>>>
>>>>>>>> Doubt what could be happening? Something is definitely
>>>>>>>> changing the Proxy URI.
>>>>>>> When you said changing, I imagined that meaning it had value x
>>>>>>> at some point and then value y later, where neither of those
>>>>>>> values was null.
>>>>>>
>>>>>> Correct. This is what I observed.
>>>>> The code is like this:
>>>>>
>>>>> protected void unloaded(InternalEObject internalEObject)
>>>>> {
>>>>> // Ensure that an unresolved containment proxy's URI isn't reset.
>>>>> //
>>>>> if (!internalEObject.eIsProxy())
>>>>> {
>>>>>
>>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)));
>>>>>
>>>>> }
>>>>> internalEObject.eAdapters().clear();
>>>>> }
>>>>>
>>>>> which would appear to make it impossible for unloading to change
>>>>> the proxy URI from one non-null value to another. What can I say?
>>>>>>
>>>>>>> Deleting a resource definitely turns all the objects into
>>>>>>> proxies and I definitely expect that resource.delete will result
>>>>>>> in objects that don't resolve at all anymore because the
>>>>>>> underlying resource where they live is also deleted.
>>>>>>
>>>>>> This is not what I observed. But remember, my proxies do not
>>>>>> belong to the deleted resource.
>>>>>>
>>>>>>>>
>>>>>>>>>> Is this a bug or am I missing something?
>>>>>>>>> I imagine that once you delete objectA you won't be able to
>>>>>>>>> resolve any proxies that objectA references, containment or
>>>>>>>>> otherwise. So best to ensure the proxies are resolved...
>>>>>>>>
>>>>>>>> Easier said than done. Again, I don't see why the proxy URI
>>>>>>>> would change. If the proxy URI doesn't change, then the URI
>>>>>>>> would still be resolvable and this problem would be avoided
>>>>>>>> without having to do extra work.
>>>>>>> Again this comment implies it has a good non null proxy URI that
>>>>>>> later become a bad non null proxy URI. I can't begin to guess
>>>>>>> at how such a thing is possible.
>>>>>>
>>>>>> Me neither, but I've watched it happen.
>>>>> So you should be able to see on the stack what lead to such a
>>>>> situation. I can only imagine.
>>>>>>
>>>>>>>> After all, I don't necessarily know how many layers of
>>>>>>>> proxies I need to walk through and resolve.
>>>>>>> EcoreUtil.resolveAll will resolve all proxies that are resolvable.
>>>>>>>>
>>>>>>>> If there are too many layers, it came become problematic since
>>>>>>>> the bug only shows up when there are unresolved proxies and
>>>>>>>> then it becomes an order of operation problem. If the proxy
>>>>>>>> URI doesn't become munged, then the order of operation no
>>>>>>>> longer matters.
>>>>>>> Are you doing anything to clean up references to the deleted
>>>>>>> objects?
>>>>>>
>>>>>> I'm not sure I understand that question. I am not knowingly
>>>>>> changing the URIs inside the proxies when I delete their
>>>>>> containing eObject's resource.
>>>>> You should expect that deleting a resource will require you to
>>>>> clean up all references to the contained object. It doesn't sound
>>>>> like you're doing that or even expecting to do that. Something is
>>>>> wrong with that picture. It's starting to sound like you really
>>>>> want to clear your resource before you delete it so that the
>>>>> objects themselves will end up being contained in a different
>>>>> resource, rather than being deleted (turned into proxies).
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Delete changes containment proxy values [message #550626 is a reply to message #550585] |
Tue, 03 August 2010 22:37 |
Stephen McCants
Messages: 92
Registered: July 2009 |
Member |
|
|
Ed,
You mistake my frustration being solely with EMF Core. It is not, but it is with Eclipse as a
whole. That isn't fair to you, as someone who works very hard to make EMF the best it can be, but
my frustration with Eclipse is still very real. I did a quick count of open bugs (or ones where I
disagree with the resolution, although that was only one bug) and came up with 23. Many have been
open for more than a year and some for several years. I didn't even find the EMF Core one that you
referred to (probably, because like you, I don't consider it a high priority).
This particular problem that I found, I thought was interesting, but at this time, I'm not willing
to put more work into unwinding it. I do have it worked around or I would be more interested in
fixing it.
Thanks for all you do to make EMF robust.
--Stephen
Ed Merks wrote:
> Stephen,
>
> You have one reported problem in EMF core. When asked for a test case,
> you didn't provide one. How should I interpret that fact? I read it
> as, "this problem isn't worth spending the time to create a test case"
> which makes me wonder, "is it worth spending the time to investigate?"
> Given that there is little value in defining a container reference for a
> map entry---it doesn't even have any public API---it simply doesn't
> factor high in the list of things on which to spend time.
>
>
> Stephen McCants wrote:
>> Ed,
>> In my experience, reported problems are only rarely fixed.
>> --Stephen
>>
>> Ed Merks wrote:
>>> Stephen,
>>>
>>> That's unfortunate. :-( Unreported problems definitely don't get fixed.
>>>
>>>
>>> Stephen McCants wrote:
>>>> I've decided not to bother with a test case, although I believe the
>>>> problem is very real.
>>>> --Stephen
>>>>
>>>> Stephen McCants wrote:
>>>>> Hi Ed,
>>>>> I think we have successfully failed to communicate enough that
>>>>> a test case is our only hope. It is getting much too difficult to
>>>>> read the posts below, even though I think I see several places
>>>>> where I've failed to convey what is happening.
>>>>> I may try to put a test case together and see if I can
>>>>> demonstrate this problem in a neutral environment.
>>>>>
>>>>> --Stephen
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Stephen,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Stephen McCants wrote:
>>>>>>> Hi Ed,
>>>>>>> I do not think we are communicating very well. You've now
>>>>>>> said that what I'm observing is impossible.
>>>>>> It's not clear to me what you're observing. No doubt a test case
>>>>>> is worth a thousand newsgroup posts.
>>>>>>>
>>>>>>>>>> Stephen McCants wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>> I've found what I think is an EMF bug, but I could be
>>>>>>>>>>> wrong.
>>>>>>>>>> Probably. :-P
>>>>>>>>>>> I have containment proxies enabled and I have objectA in
>>>>>>>>>>> resource1 that has a containment reference to objectB that is
>>>>>>>>>>> in resource2. If both of the objects are loaded and I delete
>>>>>>>>>>> objectA and then objectB, things work correctly.
>>>>>>>>>> As in delete command?
>>>>>>>>>
>>>>>>>>> resource.delete(null);
>>>>>>>> That will turn all contained objects into proxies. I.e.,
>>>>>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
>>>>>>>> where uri is the URI of the containing resource.
>>>>>>>
>>>>>>> That is not the behavior I'm observing.
>>>>>> You've stepped through the calls when you invoke
>>>>>> resource.delete(null)? I'd expect it to end up in
>>>>>> ResourceImpl.doUnload which would call unloaded for the whole tree
>>>>>> of objects doing exactly what I described above.
>>>>>>> In fact, if I resolve the proxies ahead of time, then
>>>>>>> everything works correctly. They are not turned back into proxies.
>>>>>> What is resource.delete actually doing in this case?
>>>>>>> I suspect this is because I have "containment proxies" enabled,
>>>>>>> so that EMF recognizes that these proxies may belong to another
>>>>>>> resource and not the resource that was deleted (which is the case
>>>>>>> in my example).
>>>>>>>
>>>>>>>>>
>>>>>>>>>>> However, if objectA has an EProxy for objectB and I
>>>>>>>>>>> delete objectA, then something changes/munges/breaks the
>>>>>>>>>>> proxy URI for objectB.
>>>>>>>>>> It changes from what to what?
>>>>>>>>>
>>>>>>>>> I'd have to rebreak my code to see exactly what it became.
>>>>>>>>> What it was doing was not obvious to me, but it I think it was
>>>>>>>>> trying to make objectB a proxy that pointed into the parent
>>>>>>>>> resource for resource1.
>>>>>>>> I'd expect it to use resource B.
>>>>>>>
>>>>>>> It does not.
>>>>>> What does it use?
>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Then when I try to delete objectB, it fails because the URI
>>>>>>>>>>> is wrong.
>>>>>>>>>
>>>>>>>>>> Once objectA isn't contained by a resource set, proxies won't
>>>>>>>>>> resolve anymore.
>>>>>>>>>
>>>>>>>>> Why not? Object B is a proxy to a different resource. That
>>>>>>>>> resource has not been deleted.
>>>>>>>> The resource set needs to be reachable from the object (i.e.,
>>>>>>>> x.eResource() != null && x.eResource().getResourceSet() != null)
>>>>>>>> for it to be able to resolve proxies.
>>>>>>>
>>>>>>> Even when you are dealing with proxies that belong to a different
>>>>>>> resource than their containing eObject?
>>>>>> Have a look at the logic followed by EcoreUtil.resolve(EObject,
>>>>>> EObject).
>>>>>>>
>>>>>>> In my case, there is another eObject that is the container for
>>>>>>> eObject A (call it eObject Z). EObject Z belongs to resource Z.
>>>>>>> If I'm not mistaken, A.eResource() after A's resource has been
>>>>>>> deleted will return resource Z.
>>>>>> Notice that you've provided yet another new piece of information I
>>>>>> couldn't have known about before, I.e., Z and its resource. Also,
>>>>>> here you're talking about removing A's resource where up to now I
>>>>>> would have though you were deleting B's resource...
>>>>>>
>>>>>> I would expect A itself to be turned into a proxy when its
>>>>>> resource is deleted. Is that happening? I'd also expect the
>>>>>> underlying resource to be removed from the workspace and for the A
>>>>>> proxy to be unresolvable. You might not notice that A is an
>>>>>> unresolveable proxy because all of A's features will remain
>>>>>> populated; as such, you might be under the impression that A has
>>>>>> moved to be a child of the Z resource. If that's what you want,
>>>>>> you should remove A from A's resource and then delete the empty
>>>>>> resource that's left.
>>>>>>> So, the resource set is still accessible.
>>>>>> So it would appear, but how am I to know?
>>>>>>>
>>>>>>>>>
>>>>>>>>>>> I looked for the code that is making the change, but was
>>>>>>>>>>> unable to find it.
>>>>>>>>>> Setting breakpoints you mean?
>>>>>>>>>
>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>>>> If I'm careful, I can reverse the behaviour (delete
>>>>>>>>>>> objectB before objectA) and it works around the problem, but
>>>>>>>>>>> it seems to me that when you have containment proxies,
>>>>>>>>>>> deleting the container should not alter the proxy's URI.
>>>>>>>>>> There are so few places that call InternalEObject.eSetProxyURI
>>>>>>>>>> that I doubt this could be happening.
>>>>>>>>>
>>>>>>>>> Doubt what could be happening? Something is definitely
>>>>>>>>> changing the Proxy URI.
>>>>>>>> When you said changing, I imagined that meaning it had value x
>>>>>>>> at some point and then value y later, where neither of those
>>>>>>>> values was null.
>>>>>>>
>>>>>>> Correct. This is what I observed.
>>>>>> The code is like this:
>>>>>>
>>>>>> protected void unloaded(InternalEObject internalEObject)
>>>>>> {
>>>>>> // Ensure that an unresolved containment proxy's URI isn't reset.
>>>>>> //
>>>>>> if (!internalEObject.eIsProxy())
>>>>>> {
>>>>>>
>>>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)));
>>>>>>
>>>>>> }
>>>>>> internalEObject.eAdapters().clear();
>>>>>> }
>>>>>>
>>>>>> which would appear to make it impossible for unloading to change
>>>>>> the proxy URI from one non-null value to another. What can I say?
>>>>>>>
>>>>>>>> Deleting a resource definitely turns all the objects into
>>>>>>>> proxies and I definitely expect that resource.delete will result
>>>>>>>> in objects that don't resolve at all anymore because the
>>>>>>>> underlying resource where they live is also deleted.
>>>>>>>
>>>>>>> This is not what I observed. But remember, my proxies do not
>>>>>>> belong to the deleted resource.
>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Is this a bug or am I missing something?
>>>>>>>>>> I imagine that once you delete objectA you won't be able to
>>>>>>>>>> resolve any proxies that objectA references, containment or
>>>>>>>>>> otherwise. So best to ensure the proxies are resolved...
>>>>>>>>>
>>>>>>>>> Easier said than done. Again, I don't see why the proxy URI
>>>>>>>>> would change. If the proxy URI doesn't change, then the URI
>>>>>>>>> would still be resolvable and this problem would be avoided
>>>>>>>>> without having to do extra work.
>>>>>>>> Again this comment implies it has a good non null proxy URI that
>>>>>>>> later become a bad non null proxy URI. I can't begin to guess
>>>>>>>> at how such a thing is possible.
>>>>>>>
>>>>>>> Me neither, but I've watched it happen.
>>>>>> So you should be able to see on the stack what lead to such a
>>>>>> situation. I can only imagine.
>>>>>>>
>>>>>>>>> After all, I don't necessarily know how many layers of
>>>>>>>>> proxies I need to walk through and resolve.
>>>>>>>> EcoreUtil.resolveAll will resolve all proxies that are resolvable.
>>>>>>>>>
>>>>>>>>> If there are too many layers, it came become problematic since
>>>>>>>>> the bug only shows up when there are unresolved proxies and
>>>>>>>>> then it becomes an order of operation problem. If the proxy
>>>>>>>>> URI doesn't become munged, then the order of operation no
>>>>>>>>> longer matters.
>>>>>>>> Are you doing anything to clean up references to the deleted
>>>>>>>> objects?
>>>>>>>
>>>>>>> I'm not sure I understand that question. I am not knowingly
>>>>>>> changing the URIs inside the proxies when I delete their
>>>>>>> containing eObject's resource.
>>>>>> You should expect that deleting a resource will require you to
>>>>>> clean up all references to the contained object. It doesn't sound
>>>>>> like you're doing that or even expecting to do that. Something is
>>>>>> wrong with that picture. It's starting to sound like you really
>>>>>> want to clear your resource before you delete it so that the
>>>>>> objects themselves will end up being contained in a different
>>>>>> resource, rather than being deleted (turned into proxies).
|
|
|
| Re: Delete changes containment proxy values [message #550837 is a reply to message #550626] |
Wed, 04 August 2010 13:28 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stephen,
Comments below.
Stephen McCants wrote:
> Ed,
> You mistake my frustration being solely with EMF Core.
That's the part I take personally anyway...
> It is not, but it is with Eclipse as a whole.
I see.
> That isn't fair to you, as someone who works very hard to make EMF the
> best it can be, but my frustration with Eclipse is still very real.
I'm very familiar with frustration...
> I did a quick count of open bugs (or ones where I disagree with the
> resolution, although that was only one bug) and came up with 23.
Yes, I was having a look at the bugs you opened as well. I saw a bunch
related to compare, for example. It looked like those folks tried to
help with most of them...
> Many have been open for more than a year and some for several years.
In a few cases, where I was really frustrated, I took it upon myself to
"fix" the problem. Often the fix wasn't the correct one, but it did
prompt the committers to have a close look and propose a better fix.
After all, an important principal to keep in mind is the balance between
how much effort is invested by the person reporting a problem and the
person having to fix it (for free). Back in my corporate days, this
issue of "problem dumping"---usually late on a Friday afternoon, at
which point it was of course a critical problem---was very pronounced.
As resource for my team dwindled---if you don't have a huge backlog of
open problems, you clearly have too much resource---I'd repeat the
comment "If this problem is really important to you, you'd invest more
effort in helping resolving it." One quickly discovers that many
problems really aren't all that important when real investment is
required to fix it.
All that is to explain that you're likely reporting problems to people
who have developed a thick skin with respect to problem reports.
> I didn't even find the EMF Core one that you referred to (probably,
> because like you, I don't consider it a high priority).
It's definitely a real problem. I did eventually create a test case,
but of course one test was to see if you'd create one, especially given
the comments about cross resource containment in the bugzilla. I doubt
that would work well...
> This particular problem that I found, I thought was interesting,
> but at this time, I'm not willing to put more work into unwinding it.
> I do have it worked around or I would be more interested in fixing it.
It does sound interesting, but I also suspect it's just working within
the bounds of what's to be expected. I could be wrong...
> Thanks for all you do to make EMF robust.
The best way to make something successful is of course to make it work
well and to make sure the clients are successful using it.
>
> --Stephen
>
> Ed Merks wrote:
>> Stephen,
>>
>> You have one reported problem in EMF core. When asked for a test
>> case, you didn't provide one. How should I interpret that fact? I
>> read it as, "this problem isn't worth spending the time to create a
>> test case" which makes me wonder, "is it worth spending the time to
>> investigate?" Given that there is little value in defining a
>> container reference for a map entry---it doesn't even have any public
>> API---it simply doesn't factor high in the list of things on which to
>> spend time.
>>
>>
>> Stephen McCants wrote:
>>> Ed,
>>> In my experience, reported problems are only rarely fixed.
>>> --Stephen
>>>
>>> Ed Merks wrote:
>>>> Stephen,
>>>>
>>>> That's unfortunate. :-( Unreported problems definitely don't get
>>>> fixed.
>>>>
>>>>
>>>> Stephen McCants wrote:
>>>>> I've decided not to bother with a test case, although I believe
>>>>> the problem is very real.
>>>>> --Stephen
>>>>>
>>>>> Stephen McCants wrote:
>>>>>> Hi Ed,
>>>>>> I think we have successfully failed to communicate enough
>>>>>> that a test case is our only hope. It is getting much too
>>>>>> difficult to read the posts below, even though I think I see
>>>>>> several places where I've failed to convey what is happening.
>>>>>> I may try to put a test case together and see if I can
>>>>>> demonstrate this problem in a neutral environment.
>>>>>>
>>>>>> --Stephen
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>> Stephen,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Stephen McCants wrote:
>>>>>>>> Hi Ed,
>>>>>>>> I do not think we are communicating very well. You've now
>>>>>>>> said that what I'm observing is impossible.
>>>>>>> It's not clear to me what you're observing. No doubt a test
>>>>>>> case is worth a thousand newsgroup posts.
>>>>>>>>
>>>>>>>>>>> Stephen McCants wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> I've found what I think is an EMF bug, but I could be
>>>>>>>>>>>> wrong.
>>>>>>>>>>> Probably. :-P
>>>>>>>>>>>> I have containment proxies enabled and I have objectA in
>>>>>>>>>>>> resource1 that has a containment reference to objectB that
>>>>>>>>>>>> is in resource2. If both of the objects are loaded and I
>>>>>>>>>>>> delete objectA and then objectB, things work correctly.
>>>>>>>>>>> As in delete command?
>>>>>>>>>>
>>>>>>>>>> resource.delete(null);
>>>>>>>>> That will turn all contained objects into proxies. I.e.,
>>>>>>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)))
>>>>>>>>> where uri is the URI of the containing resource.
>>>>>>>>
>>>>>>>> That is not the behavior I'm observing.
>>>>>>> You've stepped through the calls when you invoke
>>>>>>> resource.delete(null)? I'd expect it to end up in
>>>>>>> ResourceImpl.doUnload which would call unloaded for the whole
>>>>>>> tree of objects doing exactly what I described above.
>>>>>>>> In fact, if I resolve the proxies ahead of time, then
>>>>>>>> everything works correctly. They are not turned back into
>>>>>>>> proxies.
>>>>>>> What is resource.delete actually doing in this case?
>>>>>>>> I suspect this is because I have "containment proxies" enabled,
>>>>>>>> so that EMF recognizes that these proxies may belong to another
>>>>>>>> resource and not the resource that was deleted (which is the
>>>>>>>> case in my example).
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> However, if objectA has an EProxy for objectB and I
>>>>>>>>>>>> delete objectA, then something changes/munges/breaks the
>>>>>>>>>>>> proxy URI for objectB.
>>>>>>>>>>> It changes from what to what?
>>>>>>>>>>
>>>>>>>>>> I'd have to rebreak my code to see exactly what it became.
>>>>>>>>>> What it was doing was not obvious to me, but it I think it
>>>>>>>>>> was trying to make objectB a proxy that pointed into the
>>>>>>>>>> parent resource for resource1.
>>>>>>>>> I'd expect it to use resource B.
>>>>>>>>
>>>>>>>> It does not.
>>>>>>> What does it use?
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Then when I try to delete objectB, it fails because the URI
>>>>>>>>>>>> is wrong.
>>>>>>>>>>
>>>>>>>>>>> Once objectA isn't contained by a resource set, proxies
>>>>>>>>>>> won't resolve anymore.
>>>>>>>>>>
>>>>>>>>>> Why not? Object B is a proxy to a different resource. That
>>>>>>>>>> resource has not been deleted.
>>>>>>>>> The resource set needs to be reachable from the object (i.e.,
>>>>>>>>> x.eResource() != null && x.eResource().getResourceSet() !=
>>>>>>>>> null) for it to be able to resolve proxies.
>>>>>>>>
>>>>>>>> Even when you are dealing with proxies that belong to a
>>>>>>>> different resource than their containing eObject?
>>>>>>> Have a look at the logic followed by EcoreUtil.resolve(EObject,
>>>>>>> EObject).
>>>>>>>>
>>>>>>>> In my case, there is another eObject that is the container for
>>>>>>>> eObject A (call it eObject Z). EObject Z belongs to resource
>>>>>>>> Z. If I'm not mistaken, A.eResource() after A's resource has
>>>>>>>> been deleted will return resource Z.
>>>>>>> Notice that you've provided yet another new piece of information
>>>>>>> I couldn't have known about before, I.e., Z and its resource.
>>>>>>> Also, here you're talking about removing A's resource where up
>>>>>>> to now I would have though you were deleting B's resource...
>>>>>>>
>>>>>>> I would expect A itself to be turned into a proxy when its
>>>>>>> resource is deleted. Is that happening? I'd also expect the
>>>>>>> underlying resource to be removed from the workspace and for the
>>>>>>> A proxy to be unresolvable. You might not notice that A is an
>>>>>>> unresolveable proxy because all of A's features will remain
>>>>>>> populated; as such, you might be under the impression that A has
>>>>>>> moved to be a child of the Z resource. If that's what you want,
>>>>>>> you should remove A from A's resource and then delete the empty
>>>>>>> resource that's left.
>>>>>>>> So, the resource set is still accessible.
>>>>>>> So it would appear, but how am I to know?
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> I looked for the code that is making the change, but was
>>>>>>>>>>>> unable to find it.
>>>>>>>>>>> Setting breakpoints you mean?
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>>>> If I'm careful, I can reverse the behaviour (delete
>>>>>>>>>>>> objectB before objectA) and it works around the problem,
>>>>>>>>>>>> but it seems to me that when you have containment proxies,
>>>>>>>>>>>> deleting the container should not alter the proxy's URI.
>>>>>>>>>>> There are so few places that call
>>>>>>>>>>> InternalEObject.eSetProxyURI that I doubt this could be
>>>>>>>>>>> happening.
>>>>>>>>>>
>>>>>>>>>> Doubt what could be happening? Something is definitely
>>>>>>>>>> changing the Proxy URI.
>>>>>>>>> When you said changing, I imagined that meaning it had value x
>>>>>>>>> at some point and then value y later, where neither of those
>>>>>>>>> values was null.
>>>>>>>>
>>>>>>>> Correct. This is what I observed.
>>>>>>> The code is like this:
>>>>>>>
>>>>>>> protected void unloaded(InternalEObject internalEObject)
>>>>>>> {
>>>>>>> // Ensure that an unresolved containment proxy's URI isn't
>>>>>>> reset.
>>>>>>> //
>>>>>>> if (!internalEObject.eIsProxy())
>>>>>>> {
>>>>>>>
>>>>>>> internalEObject.eSetProxyURI(uri.appendFragment(getURIFragme nt(internalEObject)));
>>>>>>>
>>>>>>> }
>>>>>>> internalEObject.eAdapters().clear();
>>>>>>> }
>>>>>>>
>>>>>>> which would appear to make it impossible for unloading to change
>>>>>>> the proxy URI from one non-null value to another. What can I say?
>>>>>>>>
>>>>>>>>> Deleting a resource definitely turns all the objects into
>>>>>>>>> proxies and I definitely expect that resource.delete will
>>>>>>>>> result in objects that don't resolve at all anymore because
>>>>>>>>> the underlying resource where they live is also deleted.
>>>>>>>>
>>>>>>>> This is not what I observed. But remember, my proxies do not
>>>>>>>> belong to the deleted resource.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Is this a bug or am I missing something?
>>>>>>>>>>> I imagine that once you delete objectA you won't be able to
>>>>>>>>>>> resolve any proxies that objectA references, containment or
>>>>>>>>>>> otherwise. So best to ensure the proxies are resolved...
>>>>>>>>>>
>>>>>>>>>> Easier said than done. Again, I don't see why the proxy URI
>>>>>>>>>> would change. If the proxy URI doesn't change, then the URI
>>>>>>>>>> would still be resolvable and this problem would be avoided
>>>>>>>>>> without having to do extra work.
>>>>>>>>> Again this comment implies it has a good non null proxy URI
>>>>>>>>> that later become a bad non null proxy URI. I can't begin to
>>>>>>>>> guess at how such a thing is possible.
>>>>>>>>
>>>>>>>> Me neither, but I've watched it happen.
>>>>>>> So you should be able to see on the stack what lead to such a
>>>>>>> situation. I can only imagine.
>>>>>>>>
>>>>>>>>>> After all, I don't necessarily know how many layers of
>>>>>>>>>> proxies I need to walk through and resolve.
>>>>>>>>> EcoreUtil.resolveAll will resolve all proxies that are
>>>>>>>>> resolvable.
>>>>>>>>>>
>>>>>>>>>> If there are too many layers, it came become problematic
>>>>>>>>>> since the bug only shows up when there are unresolved proxies
>>>>>>>>>> and then it becomes an order of operation problem. If the
>>>>>>>>>> proxy URI doesn't become munged, then the order of operation
>>>>>>>>>> no longer matters.
>>>>>>>>> Are you doing anything to clean up references to the deleted
>>>>>>>>> objects?
>>>>>>>>
>>>>>>>> I'm not sure I understand that question. I am not knowingly
>>>>>>>> changing the URIs inside the proxies when I delete their
>>>>>>>> containing eObject's resource.
>>>>>>> You should expect that deleting a resource will require you to
>>>>>>> clean up all references to the contained object. It doesn't
>>>>>>> sound like you're doing that or even expecting to do that.
>>>>>>> Something is wrong with that picture. It's starting to sound
>>>>>>> like you really want to clear your resource before you delete it
>>>>>>> so that the objects themselves will end up being contained in a
>>>>>>> different resource, rather than being deleted (turned into
>>>>>>> proxies).
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Sep 20 15:31:26 GMT 2024
Powered by FUDForum. Page generated in 0.04253 seconds |
] 
Search
Help
Register
Login
Home
