Eclipse Community Forums: EMF » [CDO] Understanding proxy state.

Help

Home

Home » Modeling » EMF » [CDO] Understanding proxy state.

Show: Today's Messages :: Show Polls :: Message Navigator

[CDO] Understanding proxy state. [message #1060435]

Fri, 24 May 2013 15:45

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

Hi,

I am trying to understand when and how objects in an CDO list are of
type CDOProxy. I notice certain behaviour when an object in the list is
in such a state, I provide some examples here:

1. When using the CDO UI (Which I integrated in NetXStudio), I get
sometimes objects in the proxy state, see attached screenshot.
(Properties are empty). I would like to understand, why the object is
not simply proxy resolved and showed?.

2. Some time ago, I registered this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=316273
Although the bug is closed, I still don't have this working properly.
A new debug round revealed today that, the equality (code snippet below)
fails when the object to compare is of type CDOProxyElement.
(See 2nd attached screenshot).

@Override
public boolean equals(Object obj)
{
if (obj == this)
{
return true;
}

if (obj != null && obj.getClass() == getClass())
{
AbstractCDOIDLong that = (AbstractCDOIDLong)obj;
return value == that.value;
}

return false;
}

Now, with these examples, the question pops up. What do I need to do as
a "client" to CDO, so proxies are resolved whenever needed? I.e. for
showing in UI or doing equality checks like the EMF.Edit RemoveCommand
does in bug 316273

Should I access some parts of the object to trigger Proxy resolvement?
Or turned around, would it stay a CDOElementProxy if I don't access some
parts of the object?

Thanks for all the help!
Christophe

Attachment: CDOProxy state.png
(Size: 214.92KB, Downloaded 114 times)
Attachment: CDOProxyEquality.png
(Size: 95.66KB, Downloaded 115 times)

Report message to a moderator

Re: [CDO] Understanding proxy state. [message #1060439 is a reply to message #1060435]

Fri, 24 May 2013 15:57

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

Just to add that my session is configured like this:

cdoSession.options().setCollectionLoadingPolicy(
CDOUtil.createCollectionLoadingPolicy(0, 300));

so this means don't do any initial loading of a collections, but
it seems to mean, that the parent will be of type CDOElementProxy until
any of it's children collections is accessed? Is this the correct
interpretation?

Thanks
Christophe

On 24-05-13 17:45, Christophe Bouhier wrote:
> Hi,
>
> I am trying to understand when and how objects in an CDO list are of
> type CDOProxy. I notice certain behaviour when an object in the list is
> in such a state, I provide some examples here:
>
>
> 1. When using the CDO UI (Which I integrated in NetXStudio), I get
> sometimes objects in the proxy state, see attached screenshot.
> (Properties are empty). I would like to understand, why the object is
> not simply proxy resolved and showed?.
>
> 2. Some time ago, I registered this bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=316273
> Although the bug is closed, I still don't have this working properly.
> A new debug round revealed today that, the equality (code snippet below)
> fails when the object to compare is of type CDOProxyElement.
> (See 2nd attached screenshot).
>
> @Override
> public boolean equals(Object obj)
> {
> if (obj == this)
> {
> return true;
> }
>
> if (obj != null && obj.getClass() == getClass())
> {
> AbstractCDOIDLong that = (AbstractCDOIDLong)obj;
> return value == that.value;
> }
>
> return false;
> }
>
> Now, with these examples, the question pops up. What do I need to do as
> a "client" to CDO, so proxies are resolved whenever needed? I.e. for
> showing in UI or doing equality checks like the EMF.Edit RemoveCommand
> does in bug 316273
>
> Should I access some parts of the object to trigger Proxy resolvement?
> Or turned around, would it stay a CDOElementProxy if I don't access some
> parts of the object?
>
> Thanks for all the help!
> Christophe
>

Report message to a moderator

Re: [CDO] Understanding proxy state. [message #1060484 is a reply to message #1060435]

Sat, 25 May 2013 07:27

Eike Stepper

Messages: 6683
Registered: July 2009

Senior Member

Am 24.05.2013 17:45, schrieb Christophe Bouhier:
> Hi,
>
> I am trying to understand when and how objects in an CDO list are of type CDOProxy.
A list contains an instance of CDOElementProxy if partial collection loading is enabled and the respective list index
has not been resolved (loaded), yet.

> I notice certain behaviour when an object in the list is in such a state, I provide some examples here:
>
>
> 1. When using the CDO UI (Which I integrated in NetXStudio), I get sometimes objects in the proxy state, see attached
> screenshot. (Properties are empty). I would like to understand, why the object is not simply proxy resolved and showed?.
Hmm, are you confusing the CDOState.PROXY of a CDOObject with a CDOElementProxy in a CDOList? They're totally different
things.

>
> 2. Some time ago, I registered this bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=316273
> Although the bug is closed, I still don't have this working properly.
If the already reported problem still occurs please reopen that bugzilla, otherwise plese open a new one.

> A new debug round revealed today that, the equality (code snippet below) fails when the object to compare is of type
> CDOProxyElement.
You mean CDOElementProxy?

> (See 2nd attached screenshot).
>
> @Override
> public boolean equals(Object obj)
> {
> if (obj == this)
> {
> return true;
> }
>
> if (obj != null && obj.getClass() == getClass())
> {
> AbstractCDOIDLong that = (AbstractCDOIDLong)obj;
> return value == that.value;
> }
>
> return false;
> }
I can't find this equals() method in CDOElementProxyImpl. Where is it?

>
> Now, with these examples, the question pops up. What do I need to do as a "client" to CDO, so proxies are resolved
> whenever needed? I.e. for showing in UI or doing equality checks like the EMF.Edit RemoveCommand does in bug 316273
We first need to clarify what proxies you mean, CDOObject in CDOState.PROXY or CDOElementProxy in a CDOList. I suspect
the latter. Thos are resolved by the policy you set via CDOSession.Options.setCollectionLoadingPolicy().

>
> Should I access some parts of the object to trigger Proxy resolvement?
Yes, list.get(i) should resolve (load+set) them with your CDOCollectionLoadingPolicy.

> Or turned around, would it stay a CDOElementProxy if I don't access some parts of the object?
Yes, that's the purpose of partially loaded collections ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] Understanding proxy state. [message #1060485 is a reply to message #1060439]

Sat, 25 May 2013 07:29

Eike Stepper

Messages: 6683
Registered: July 2009

Senior Member

Am 24.05.2013 17:57, schrieb Christophe Bouhier:
> Just to add that my session is configured like this:
>
> cdoSession.options().setCollectionLoadingPolicy(
> CDOUtil.createCollectionLoadingPolicy(0, 300));
>
> so this means don't do any initial loading of a collections,
Yes.

> but it seems to mean, that the parent
Parent of what?

> will be of type CDOElementProxy until any of it's children collections is accessed? Is this the correct interpretation?
I don't seem to fully understand it. Did my answer to your previous post help?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

>
> Thanks
> Christophe
>
>
> On 24-05-13 17:45, Christophe Bouhier wrote:
>> Hi,
>>
>> I am trying to understand when and how objects in an CDO list are of
>> type CDOProxy. I notice certain behaviour when an object in the list is
>> in such a state, I provide some examples here:
>>
>>
>> 1. When using the CDO UI (Which I integrated in NetXStudio), I get
>> sometimes objects in the proxy state, see attached screenshot.
>> (Properties are empty). I would like to understand, why the object is
>> not simply proxy resolved and showed?.
>>
>> 2. Some time ago, I registered this bug:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=316273
>> Although the bug is closed, I still don't have this working properly.
>> A new debug round revealed today that, the equality (code snippet below)
>> fails when the object to compare is of type CDOProxyElement.
>> (See 2nd attached screenshot).
>>
>> @Override
>> public boolean equals(Object obj)
>> {
>> if (obj == this)
>> {
>> return true;
>> }
>>
>> if (obj != null && obj.getClass() == getClass())
>> {
>> AbstractCDOIDLong that = (AbstractCDOIDLong)obj;
>> return value == that.value;
>> }
>>
>> return false;
>> }
>>
>> Now, with these examples, the question pops up. What do I need to do as
>> a "client" to CDO, so proxies are resolved whenever needed? I.e. for
>> showing in UI or doing equality checks like the EMF.Edit RemoveCommand
>> does in bug 316273
>>
>> Should I access some parts of the object to trigger Proxy resolvement?
>> Or turned around, would it stay a CDOElementProxy if I don't access some
>> parts of the object?
>>
>> Thanks for all the help!
>> Christophe
>>
>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] Understanding proxy state. [message #1060496 is a reply to message #1060484]

Sat, 25 May 2013 11:59

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

On 25-05-13 09:27, Eike Stepper wrote:
> Am 24.05.2013 17:45, schrieb Christophe Bouhier:
>> Hi,
>>
>> I am trying to understand when and how objects in an CDO list are of
>> type CDOProxy.
> A list contains an instance of CDOElementProxy if partial collection
> loading is enabled and the respective list index has not been resolved
> (loaded), yet.
>
>> I notice certain behaviour when an object in the list is in such a
>> state, I provide some examples here:
>>
>>
>> 1. When using the CDO UI (Which I integrated in NetXStudio), I get
>> sometimes objects in the proxy state, see attached screenshot.
>> (Properties are empty). I would like to understand, why the object is
>> not simply proxy resolved and showed?.
> Hmm, are you confusing the CDOState.PROXY of a CDOObject with a
> CDOElementProxy in a CDOList? They're totally different things.
>
I am talking about CDOElementProxy, in the attached screenshot the
objects in the UI show as an CDOElementProxy. Why is this? The objects
in concerned have certain attributes, which I would expect to show by
an EMF.Edit Content provider. Is this a know limitation of the CDO Ui,
or is something wrong? If this is viewer is using an
AdapterFactoryLabelProvider, the ItemProvider's getText() method would
access it's attribute and it would then resolve?

>>
>> 2. Some time ago, I registered this bug:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=316273
>> Although the bug is closed, I still don't have this working properly.
> If the already reported problem still occurs please reopen that
> bugzilla, otherwise plese open a new one.
>
Only now, I understand why the problem as described occurs, perhaps
a new bug is better fitted.

>> A new debug round revealed today that, the equality (code snippet
>> below) fails when the object to compare is of type CDOProxyElement.
> You mean CDOElementProxy?
>
Yes, sorry.

>> (See 2nd attached screenshot).
>>
>> @Override
>> public boolean equals(Object obj)
>> {
>> if (obj == this)
>> {
>> return true;
>> }
>>
>> if (obj != null && obj.getClass() == getClass())
>> {
>> AbstractCDOIDLong that = (AbstractCDOIDLong)obj;
>> return value == that.value;
>> }
>>
>> return false;
>> }
> I can't find this equals() method in CDOElementProxyImpl. Where is it?
>
I am referring to the equals method in AbstractCDOIDLong which is in the
case of this bug is called along the stack in the RemoveCommand

RemoveCommand =>
-------------------
@Override
protected boolean prepare()
{
// This can execute if there is an owner list and a collection and
the owner list contains all the objects of the collection.
//
boolean result =
ownerList != null &&
collection != null &&
1. ownerList.containsAll(collection) &&
(owner == null || !domain.isReadOnly(owner.eResource()));

return result;
}

1. Calls ownerlist.containsAll(), the list of type CDOList, which
inherits from ArrayList, which ends up checking equality of
AbstractCDOIDLong. which is then false, as one of the objects in the
comparison will be of type CDOElementProxy.

>
>> Now, with these examples, the question pops up. What do I need to do
>> as a "client" to CDO, so proxies are resolved whenever needed? I.e.
>> for showing in UI or doing equality checks like the EMF.Edit
>> RemoveCommand does in bug 316273
> We first need to clarify what proxies you mean, CDOObject in
> CDOState.PROXY or CDOElementProxy in a CDOList. I suspect the latter.
yes the latter.
> Thos are resolved by the policy you set via
> CDOSession.Options.setCollectionLoadingPolicy().
>
Yes, but I notice that when an objects stays CDOElementProxy until I
access the content of one of it's contained multi-valued features. See
my first attached screenshot.

>>
>> Should I access some parts of the object to trigger Proxy resolvement?
> Yes, list.get(i) should resolve (load+set) them with your
> CDOCollectionLoadingPolicy.
>
What if the list is the result of CDOResource.getContents() ?
is it any different for the root content of a resource?

>> Or turned around, would it stay a CDOElementProxy if I don't access
>> some parts of the object?
> Yes, that's the purpose of partially loaded collections ;-)
Accessing one of it's contained EReferences yes, but the actual object
itself should resolve right?

I am not sure, I get across properly what I obeserve, Although the
effects in the attached screenshot are self-explanory I believe, did you
look at them?
I will work on a test case, and try to reproduce it. I think that will
be better.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>

Report message to a moderator

Re: [CDO] Understanding proxy state. [message #1060499 is a reply to message #1060484]

Sat, 25 May 2013 12:31

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

Report message to a moderator

Re: [CDO] Understanding proxy state. [message #1060500 is a reply to message #1060485]

Sat, 25 May 2013 12:31

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

On 25-05-13 09:29, Eike Stepper wrote:
> Am 24.05.2013 17:57, schrieb Christophe Bouhier:
>> Just to add that my session is configured like this:
>>
>> cdoSession.options().setCollectionLoadingPolicy(
>> CDOUtil.createCollectionLoadingPolicy(0, 300));
>>
>> so this means don't do any initial loading of a collections,
> Yes.
>
>> but it seems to mean, that the parent
> Parent of what?
The Container holding a collection. Isn't parent a correct description?
We should really agree on terminology... ;-)
>
>> will be of type CDOElementProxy until any of it's children collections
>> is accessed? Is this the correct interpretation?
> I don't seem to fully understand it. Did my answer to your previous post
> help?
Yes, it's tricky I will try reproduce it a test case.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>> Thanks
>> Christophe
>>
>>
>> On 24-05-13 17:45, Christophe Bouhier wrote:
>>> Hi,
>>>
>>> I am trying to understand when and how objects in an CDO list are of
>>> type CDOProxy. I notice certain behaviour when an object in the list is
>>> in such a state, I provide some examples here:
>>>
>>>
>>> 1. When using the CDO UI (Which I integrated in NetXStudio), I get
>>> sometimes objects in the proxy state, see attached screenshot.
>>> (Properties are empty). I would like to understand, why the object is
>>> not simply proxy resolved and showed?.
>>>
>>> 2. Some time ago, I registered this bug:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=316273
>>> Although the bug is closed, I still don't have this working properly.
>>> A new debug round revealed today that, the equality (code snippet below)
>>> fails when the object to compare is of type CDOProxyElement.
>>> (See 2nd attached screenshot).
>>>
>>> @Override
>>> public boolean equals(Object obj)
>>> {
>>> if (obj == this)
>>> {
>>> return true;
>>> }
>>>
>>> if (obj != null && obj.getClass() == getClass())
>>> {
>>> AbstractCDOIDLong that = (AbstractCDOIDLong)obj;
>>> return value == that.value;
>>> }
>>>
>>> return false;
>>> }
>>>
>>> Now, with these examples, the question pops up. What do I need to do as
>>> a "client" to CDO, so proxies are resolved whenever needed? I.e. for
>>> showing in UI or doing equality checks like the EMF.Edit RemoveCommand
>>> does in bug 316273
>>>
>>> Should I access some parts of the object to trigger Proxy resolvement?
>>> Or turned around, would it stay a CDOElementProxy if I don't access some
>>> parts of the object?
>>>
>>> Thanks for all the help!
>>> Christophe
>>>
>>
>

Report message to a moderator

Re: [CDO] Understanding proxy state. [message #1060523 is a reply to message #1060496]

Sun, 26 May 2013 05:20

Eike Stepper

Messages: 6683
Registered: July 2009

Senior Member

Am 25.05.2013 13:59, schrieb Christophe Bouhier:
> I am talking about CDOElementProxy, in the attached screenshot the objects in the UI show as an CDOElementProxy. Why
> is this?
In theory it's possible that somewhere in CDO a call to one of these methods is missing:

CDOListResolver.resolveProxy(CDORevision, EStructuralFeature, int, int)
CDOListResolver.resolveAllProxies(CDORevision, EStructuralFeature)

Because these methods can be expensive for long lists there's an optimization in BaseCDORevision:

/**
* @since 4.1
*/
public boolean isUnchunked()
{
return (flags & UNCHUNKED_FLAG) != 0;
}

If this flag would be wrongly set (indicating that no list of the owner object is chunked / contains CDOElementProxies)
it could also happen, that CDOElementProxies stay unresolved in the list.

> The objects
> in concerned have certain attributes, which I would expect to show by
> an EMF.Edit Content provider. Is this a know limitation of the CDO Ui, or is something wrong?
I'd say something is wrong.

> If this is viewer is using an AdapterFactoryLabelProvider, the ItemProvider's getText() method would
> access it's attribute and it would then resolve?
I think so. Please try to find out the value of the "flags" field in the owner revision.

> I am referring to the equals method in AbstractCDOIDLong
This SPI class does not exist anymore. The equals() check for all CDOID types is now in AbstractCDOID:

@Override
public boolean equals(Object obj)
{
return obj == this;
}

> which is in the case of this bug is called along the stack in the RemoveCommand
>
> RemoveCommand =>
> -------------------
> @Override
> protected boolean prepare()
> {
> // This can execute if there is an owner list and a collection and the owner list contains all the objects of the
> collection.
> //
> boolean result =
> ownerList != null &&
> collection != null &&
> 1. ownerList.containsAll(collection) &&
> (owner == null || !domain.isReadOnly(owner.eResource()));
>
> return result;
> }
>
> 1. Calls ownerlist.containsAll(),
Calls to methods that depend on linear list scans, such as contains(), containsAll() or indexOf(), are potentially
counter productive when used with partial collection loading.

> the list of type CDOList, which inherits from ArrayList,
What is the exact concrete type of that list? CDOListImpl or CDOListWithElementProxiesImpl?

> which ends up checking equality of AbstractCDOIDLong. which is then false, as one of the objects in the comparison
> will be of type CDOElementProxy.
I can offer to write additional unit tests for operations on partially loaded lists. Please submit a bugzilla.

>
>>
>>> Now, with these examples, the question pops up. What do I need to do
>>> as a "client" to CDO, so proxies are resolved whenever needed? I.e.
>>> for showing in UI or doing equality checks like the EMF.Edit
>>> RemoveCommand does in bug 316273
>> We first need to clarify what proxies you mean, CDOObject in
>> CDOState.PROXY or CDOElementProxy in a CDOList. I suspect the latter.
> yes the latter.
>> Thos are resolved by the policy you set via
>> CDOSession.Options.setCollectionLoadingPolicy().
>>
> Yes, but I notice that when an objects stays CDOElementProxy until I access the content of one of it's contained
> multi-valued features. See my first attached screenshot.
Sorry, that terminology still looks inconsistent. A CDOList (if used to implement a many-valued EReference) normally
contains CDOID instances which, in turn, "point" to target CDOObjects. With partial collection loading it happens that
not all CDOIDs are loaded for the list elements (note that on this internal level "list element" != EObject) but some
list positions are represented by CDOElementProxy instances. On this level they're not proxies for target EObjects but
for their CDOIDs.

>
>>>
>>> Should I access some parts of the object to trigger Proxy resolvement?
>> Yes, list.get(i) should resolve (load+set) them with your
>> CDOCollectionLoadingPolicy.
>>
> What if the list is the result of CDOResource.getContents() ?
> is it any different for the root content of a resource?
The question is a little tricky because there are always (at least) two lists involved, a DelegatingEcoreEList that the
application directly deals with and the backing list in the CDORevision which does all the CDOElementProxy stuff (if
it's a CDOListWithElementProxiesImpl and a CDOCollectionLoadingPolicy has been set).

The lists in the CDORevisions do not depend on the owner's EClass or feature (e.g. CDOResource.contents or not).

>
>>> Or turned around, would it stay a CDOElementProxy if I don't access
>>> some parts of the object?
>> Yes, that's the purpose of partially loaded collections ;-)
> Accessing one of it's contained EReferences yes, but the actual object itself should resolve right?
I'm confused ;-(

Have you tried to set breakpoints to narrow down the scope of a possible bug and then write a test case?

>
> I am not sure, I get across properly what I obeserve, Although the effects in the attached screenshot are
> self-explanory I believe, did you look at them?
I looked at them but they don't help to explain what happened.

> I will work on a test case, and try to reproduce it. I think that will be better.
I know it's sometimes hard without knowing all the details about CDO. Using the Net4j Introspector view and then setting
breakpoints often helps a lot.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] Understanding proxy state. [message #1060524 is a reply to message #1060500]

Sun, 26 May 2013 05:24

Eike Stepper

Messages: 6683
Registered: July 2009

Senior Member

Am 25.05.2013 14:31, schrieb Christophe Bouhier:
> On 25-05-13 09:29, Eike Stepper wrote:
>> Am 24.05.2013 17:57, schrieb Christophe Bouhier:
>>> Just to add that my session is configured like this:
>>>
>>> cdoSession.options().setCollectionLoadingPolicy(
>>> CDOUtil.createCollectionLoadingPolicy(0, 300));
>>>
>>> so this means don't do any initial loading of a collections,
>> Yes.
>>
>>> but it seems to mean, that the parent
>> Parent of what?
> The Container holding a collection. Isn't parent a correct description? We should really agree on terminology... ;-)
Hehe, I know it's often hard but it can help :P

From an EObject tree's point of view I would say "container (EObject)". "Parent" would also be okay.

From a many-valued feature's implementation list's point of view The EObject that holds the list is usually called the
lists's "owner".

>>
>>> will be of type CDOElementProxy until any of it's children collections
>>> is accessed? Is this the correct interpretation?
>> I don't seem to fully understand it. Did my answer to your previous post
>> help?
> Yes, it's tricky I will try reproduce it a test case.
Cool. Please submit a bugzilla then and we can discuss further questions/problems there ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: [CDO] Understanding proxy state. [message #1060606 is a reply to message #1060499]

Mon, 27 May 2013 09:53

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

https://bugs.eclipse.org/bugs/show_bug.cgi?id=396743

On 25-05-13 14:31, Christophe Bouhier wrote:
> On 25-05-13 09:27, Eike Stepper wrote:
>> Am 24.05.2013 17:45, schrieb Christophe Bouhier:
>>> Hi,
>>>
>>> I am trying to understand when and how objects in an CDO list are of
>>> type CDOProxy.
>> A list contains an instance of CDOElementProxy if partial collection
>> loading is enabled and the respective list index has not been resolved
>> (loaded), yet.
>>
>>> I notice certain behaviour when an object in the list is in such a
>>> state, I provide some examples here:
>>>
>>>
>>> 1. When using the CDO UI (Which I integrated in NetXStudio), I get
>>> sometimes objects in the proxy state, see attached screenshot.
>>> (Properties are empty). I would like to understand, why the object is
>>> not simply proxy resolved and showed?.
>> Hmm, are you confusing the CDOState.PROXY of a CDOObject with a
>> CDOElementProxy in a CDOList? They're totally different things.
>>
> I am talking about CDOElementProxy, in the attached screenshot the
> objects in the UI show as an CDOElementProxy. Why is this? The objects
> in concerned have certain attributes, which I would expect to show by
> an EMF.Edit Content provider. Is this a know limitation of the CDO Ui,
> or is something wrong? If this is viewer is using an
> AdapterFactoryLabelProvider, the ItemProvider's getText() method would
> access it's attribute and it would then resolve?
>
>>>
>>> 2. Some time ago, I registered this bug:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=316273
>>> Although the bug is closed, I still don't have this working properly.
>> If the already reported problem still occurs please reopen that
>> bugzilla, otherwise plese open a new one.
>>
> Only now, I understand why the problem as described occurs, perhaps
> a new bug is better fitted.
>
>>> A new debug round revealed today that, the equality (code snippet
>>> below) fails when the object to compare is of type CDOProxyElement.
>> You mean CDOElementProxy?
>>
> Yes, sorry.
>
>>> (See 2nd attached screenshot).
>>>
>>> @Override
>>> public boolean equals(Object obj)
>>> {
>>> if (obj == this)
>>> {
>>> return true;
>>> }
>>>
>>> if (obj != null && obj.getClass() == getClass())
>>> {
>>> AbstractCDOIDLong that = (AbstractCDOIDLong)obj;
>>> return value == that.value;
>>> }
>>>
>>> return false;
>>> }
>> I can't find this equals() method in CDOElementProxyImpl. Where is it?
>>
> I am referring to the equals method in AbstractCDOIDLong which is in the
> case of this bug is called along the stack in the RemoveCommand
>
> RemoveCommand =>
> -------------------
> @Override
> protected boolean prepare()
> {
> // This can execute if there is an owner list and a collection and
> the owner list contains all the objects of the collection.
> //
> boolean result =
> ownerList != null &&
> collection != null &&
> 1. ownerList.containsAll(collection) &&
> (owner == null || !domain.isReadOnly(owner.eResource()));
>
> return result;
> }
>
> 1. Calls ownerlist.containsAll(), the list of type CDOList, which
> inherits from ArrayList, which ends up checking equality of
> AbstractCDOIDLong. which is then false, as one of the objects in the
> comparison will be of type CDOElementProxy.
>
>>
>>> Now, with these examples, the question pops up. What do I need to do
>>> as a "client" to CDO, so proxies are resolved whenever needed? I.e.
>>> for showing in UI or doing equality checks like the EMF.Edit
>>> RemoveCommand does in bug 316273
>> We first need to clarify what proxies you mean, CDOObject in
>> CDOState.PROXY or CDOElementProxy in a CDOList. I suspect the latter.
> yes the latter.
>> Thos are resolved by the policy you set via
>> CDOSession.Options.setCollectionLoadingPolicy().
>>
> Yes, but I notice that when an objects stays CDOElementProxy until I
> access the content of one of it's contained multi-valued features. See
> my first attached screenshot.
>
>>>
>>> Should I access some parts of the object to trigger Proxy resolvement?
>> Yes, list.get(i) should resolve (load+set) them with your
>> CDOCollectionLoadingPolicy.
>>
> What if the list is the result of CDOResource.getContents() ?
> is it any different for the root content of a resource?
>
>>> Or turned around, would it stay a CDOElementProxy if I don't access
>>> some parts of the object?
>> Yes, that's the purpose of partially loaded collections ;-)
> Accessing one of it's contained EReferences yes, but the actual object
> itself should resolve right?
>
> I am not sure, I get across properly what I obeserve, Although the
> effects in the attached screenshot are self-explanory I believe, did you
> look at them?
> I will work on a test case, and try to reproduce it. I think that will
> be better.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>

Report message to a moderator

Previous Topic:	[Teneo] Default Value in DDL Generation
Next Topic:	problem with inheritance and access to subclass

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon May 06 02:45:15 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter