Bug 246494

Description Simon Mc Duff 2008-09-07 12:50:55 EDT

Simon,

With containment proxies, there's also the case where the container is null that we'd definitely need to walk the contents of the list to resolve proxies.  But if there is a non-null container,  and it's a proxy, and we can resolve that proxy, and the resolved result is the owner of the list, then I think we can avoid walking the list.   If you open a bugzilla feature request, I'll revisit the issue and consider which additional cases can avoid walking the list as an improved optimization.  EcoreEList.contains has parallel logic that would benefit from similar treatment...


Simon McDuff wrote: 
If I understand correctly...
 
If we resolve both the container and the object (if they are proxy)... we don't need to go through that list anymore ? (only for a containment relationship).
 
Simon
 
 
"Ed Merks" <Ed.Merks@gmail.com> a écrit dans le message de news: ga0u8r$3f4$1@build.eclipse.org...
Simon,

Comments below.

Simon McDuff wrote: 
Thank you Ed,
 
Tell me if I'm wrong but...Based on what you said
"Not that the object itself is a proxy but rather there being an object in the list that is a proxy for it."
 
Why we need to care where object  is in the list ?
I was just pointing out that there is no way to know which if any object in the list might be the proxy proxy. 

 
if we have the real object and the list contains the real object as well... we did look in the list for nothing. Right ?
Note thought that we called eInternalContainer, so the container object itself might be the proxy.

 
if we have the real object and the list contains the proxy... why we care... the proxy will load the real object that we already have... but it will never happen since the real object will detect that its owner is that container. Right ?
Not until the container itself is resolved, but it does make me think about checking that the container is a proxy and if so, trying to resolve it...

 
In both cases, we do that iteration through the list for nothing. Right ?
I hope not. :-P

 
My concern is more about performance. Since CDO have the possibility to have proxy objects... I'm reviewing bottleneck in the code with my performance framework and since I still do not understand that part...I'm asking a few questions. If we can avoid it.. why not :-)
I'll think about it some more as well.  With cross resource containment, it's also possible for the contained child not have have a container proxy and then it's reparent when the container actually resolves the proxy...

 
I'm also curious :-)
:-P

 
"Ed Merks" <Ed.Merks@gmail.com> a écrit dans le message de news: ga0qtt$o50$1@build.eclipse.org...
Simon,

Comments below.

Simon McDuff wrote: 
Hi Ed,
 
I have a stupid question.
 
I was looking at the following code in DelegatingEcoreEList.contains
 
else if (isContainment())
{
InternalEObject eObject = (InternalEObject)object;
boolean result =
eObject.eInternalContainer() == owner && 
(hasNavigableInverse() ? 
eObject.eContainerFeatureID() == getInverseFeatureID() :
InternalEObject.EOPPOSITE_FEATURE_BASE - eObject.eContainerFeatureID() == getFeatureID());
if (hasProxies() && !result)
{
for (int i = 0; i < size; ++i)
{
EObject containedEObject = resolveProxy((EObject)delegateGet(i));
if (containedEObject == object)
{
return true;
}
}
}
return result;
}
 
I understand this is an optimization.
 
I don't understand why we need to fetch all objects since we already looked at the containerID and the eINternalOwner to determine if object belong to that list.
Why we need to load every instance of the list in the case where it could be proxies ?
Because in that case, the list could contain a proxy instead of the real object.

 
If it is because object could be a proxy... so why not just resolve that specific object and test it after the same way we will do.
Not that the object itself is a proxy but rather there being an object in the list that is a proxy for it.

Like the following:
 
else if (isContainment())
{
InternalEObject eObject = (InternalEObject)object;
if (object.eIsProxy())
{
    // resolve object
}
 
return 
eObject.eInternalContainer() == owner && 
(hasNavigableInverse() ? 
eObject.eContainerFeatureID() == getInverseFeatureID() :
InternalEObject.EOPPOSITE_FEATURE_BASE - eObject.eContainerFeatureID() == getFeatureID());
 
I'm sure I overlooked something!! :-)
Resolving one end of the proxy doesn't resolve the other end. I.e., if A has a proxy reference to B' then B will have a proxy reference to A', but resolving A's proxy reference from B' to be the real B doesn't cause B's proxy reference to A' to also be resolved and we don't even know where in B's list A' actually appears.  I suppose we could avoid doing the resolves if the object itself is a proxy...  Is that really the case you are encountering though?

Usually resolveProxies is set to false containment features.  Do you have a specific need for containment proxies that are causing issues or you're just generally curious?

 
Thank you.