Home » Modeling » EMF » [CDO] dangling reference on deleted object.
|
| Re: [CDO] dangling reference on deleted object. [message #740231 is a reply to message #740205] |
Tue, 18 October 2011 09:40   |
|
Hi Christophe,
Comments below...
Am 18.10.2011 11:02, schrieb Christophe Bouhier:
> Hi there,
>
> In this scenario:
>
> Object A in CDOresourceA /repo/a/nameof_a
> Object B in CDOresourceB /repo/all_b_objects
>
>
> B has a reference to A and A has a reference to B (with an EOpposite).
>
> When I want to save the deleted A, I get a dangling reference exception, even tough I delete the reference from B to
> A. and I delete A.
Just by removing one end of a bidi reference from its container does not "cut" the bidi reference on any end. Bidi
(EOpposite) only means that, if you unset one end, the other end is automatically unset. The DanglingReferenceException
correctly reminds you to either unset the cross reference (on either end if it's bidi) or attach the ref target to a
resource of your choice.
>
> My questions: Is the order of deletion relevant? (First the object and then the reference?) or could I get this
> exception because I should also delete the opposite (From A to B) even though A is actually deleted implicitly
> deleting the reference A->B.
The more I read the more I get confused :P
The reference you're talking about, is it a containment reference? I recommend not to use the term "delete" at all,
neither in Java nor in EMF you can actually delete objects. In EMF you can detach objects by removing them from their
container feature (which leads to deletion when you commit later and haven't attached elsewhere).
BTW. a little test method says more than thousand words. In addition you'll get a fix way quicker if your test method
reproduces a bug in CDO. We have a cool end to end test framework where you can fully focus on the particular client
logic you want to test. Please let me know if yu need help with it ;-)
>
> finally, could it be that CDOresourceB should be saved explicitly?
With CDO you can't save specific resources, you can only commit all the changes to an entire resourceset (exception to
this rule: partial commits, since 4.0).
> (Object B is found through an queryXRefs, and I don't have the CDOresource in my resource set, my saving mechanism
> only saves objects which have a CDOResource contained in a resourceset, so it walks the set and saves the resources in
> it).
The save() method of CDOResourceImpl just delegates to commit() of the associated CDOTransaction.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
>
> here is the exception:
>
> Caused by: org.eclipse.emf.cdo.util.DanglingReferenceException: The object
> "NetXResource?(com.netxforge.netxstudio.library.impl.NetXResourceImpl)" is not contained in a resource
> at org.eclipse.emf.internal.cdo.view.AbstractCDOView.provideCDOID(AbstractCDOView.java:900)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.provideCDOID(CDOTransactionImpl.java:2027)
> at
> org.eclipse.emf.cdo.internal.common.revision.delta.CDOSingleValueFeatureDeltaImpl.writeValue(CDOSingleValueFeatureDeltaImpl.java:86)
> at
> org.eclipse.emf.cdo.internal.common.revision.delta.CDOSingleValueFeatureDeltaImpl.write(CDOSingleValueFeatureDeltaImpl.java:62)
> at org.eclipse.emf.cdo.internal.common.protocol.CDODataOutputImpl.writeCDOFeatureDelta(CDODataOutputImpl.java:388)
> at org.eclipse.emf.cdo.internal.common.revision.delta.CDOListFeatureDeltaImpl.write(CDOListFeatureDeltaImpl.java:136)
>
> thank you, Christophe
>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] dangling reference on deleted object. [message #740254 is a reply to message #740231] |
Tue, 18 October 2011 10:06 |
 Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Thank you sofar, See my response below.
On 18-10-11 11:40, Eike Stepper wrote:
> Hi Christophe,
>
> Comments below...
>
>
> Am 18.10.2011 11:02, schrieb Christophe Bouhier:
>> Hi there,
>>
>> In this scenario:
>>
>> Object A in CDOresourceA /repo/a/nameof_a
>> Object B in CDOresourceB /repo/all_b_objects
>>
>>
>> B has a reference to A and A has a reference to B (with an EOpposite).
>>
>> When I want to save the deleted A, I get a dangling reference
>> exception, even tough I delete the reference from B to A. and I delete A.
> Just by removing one end of a bidi reference from its container does not
> "cut" the bidi reference on any end.
Yes, I am aware of this, therefor I unset B -> A cross reference first.
Bidi (EOpposite) only means that,
> if you unset one end, the other end is automatically unset. The
> DanglingReferenceException correctly reminds you to either unset the
> cross reference (on either end if it's bidi) or attach the ref target to
> a resource of your choice.
>
>>
>> My questions: Is the order of deletion relevant? (First the object and
>> then the reference?) or could I get this exception because I should
>> also delete the opposite (From A to B) even though A is actually
>> deleted implicitly deleting the reference A->B.
> The more I read the more I get confused :P
Yes, I kind of trade in confusion these days :) Apologies, this is tough
for me as well...
>
> The reference you're talking about, is it a containment reference?
No it's a cross-ref.
I
> recommend not to use the term "delete" at all, neither in Java nor in
> EMF you can actually delete objects. In EMF you can detach objects by
> removing them from their container feature (which leads to deletion when
> you commit later and haven't attached elsewhere).
>
The term delete and remove is used by the emf.edit command framework
which I use a lot, so hence my usage of these terms. I do understand,
what you mean,however so for this case we remove A from it's container.
When committing CDOResourceA?
> BTW. a little test method says more than thousand words. In addition
> you'll get a fix way quicker if your test method reproduces a bug in
> CDO. We have a cool end to end test framework where you can fully focus
> on the particular client logic you want to test. Please let me know if
> yu need help with it ;-)
>
Yes, thank you for reminding me. I do not suspect a bug in CDO, but
simply my malusage of CDO :)
>>
>> finally, could it be that CDOresourceB should be saved explicitly?
> With CDO you can't save specific resources, you can only commit all the
> changes to an entire resourceset (exception to this rule: partial
> commits, since 4.0).
>
>> (Object B is found through an queryXRefs, and I don't have the
>> CDOresource in my resource set, my saving mechanism only saves objects
>> which have a CDOResource contained in a resourceset, so it walks the
>> set and saves the resources in it).
> The save() method of CDOResourceImpl just delegates to commit() of the
> associated CDOTransaction.
>
Yes I am aware. so does CDO automaticly commit object B, which is not in
the resource set? (Or does it resolve B and add the CDOResource
containing B to the resource set automaticly, when using queryXRefs? ).
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>>
>> here is the exception:
>>
>> Caused by: org.eclipse.emf.cdo.util.DanglingReferenceException: The
>> object
>> "NetXResource?(com.netxforge.netxstudio.library.impl.NetXResourceImpl)" is
>> not contained in a resource
>> at
>> org.eclipse.emf.internal.cdo.view.AbstractCDOView.provideCDOID(AbstractCDOView.java:900)
>>
>> at
>> org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.provideCDOID(CDOTransactionImpl.java:2027)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.delta.CDOSingleValueFeatureDeltaImpl.writeValue(CDOSingleValueFeatureDeltaImpl.java:86)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.delta.CDOSingleValueFeatureDeltaImpl.write(CDOSingleValueFeatureDeltaImpl.java:62)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.protocol.CDODataOutputImpl.writeCDOFeatureDelta(CDODataOutputImpl.java:388)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.delta.CDOListFeatureDeltaImpl.write(CDOListFeatureDeltaImpl.java:136)
>>
>>
>> thank you, Christophe
>>
>>
>>
>>
|
|
| | | |
| Re: [CDO] dangling reference on deleted object. [message #741237 is a reply to message #741205] |
Wed, 19 October 2011 10:20 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
I don't know to be honest, at some point I suspected, that the domain
would not be able to resolve the resource with the code here in the
Remove command. But this would require more investigation. I will need
to find time for this. For now, I have a workaround. BTW, I noticed that
CDO also has specialized implementations of the .edit framework. Perhaps
it's already addressed there..
@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 &&
ownerList.containsAll(collection) &&
(owner == null || !domain.isReadOnly(owner.eResource()));
return result;
}
Thanks for your support!
Christophe
On 19-10-11 11:35, Eike Stepper wrote:
> Am 19.10.2011 09:08, schrieb Christophe Bouhier:
>> Eike,
>>
>> I found the problem. The RemoveCommand for the Reference B->A was not
>> "executable".
>>
>> RemoveCommand.create(domain, referencingEObject,
>> eStructuralFeature, eObject)
>>
>> I have tried a similar case which is not a bidi reference (No
>> EOpposite), and then the remove command works as expected.
> I'm not very experienced with the edit framework because CDO mostly
> operates on the model level. Does that mean your problem is either
> solved or not CDO-related?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
|
|
|
| Re: [CDO] dangling reference on deleted object. [message #741397 is a reply to message #741237] |
Wed, 19 October 2011 13:44 |
Claes Rosell
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
Hi.
This seems to be related to the problem that I had, evaluating CDO, last
year. Something that I not yet have found time to finish.
Here is an extract from the email I sent to this list back then. If
these two problems are related, the following information might be
useful to you.
/Claes
<--->
I am currently using CDO 3.0 20100526-1334 (Helios RC2) and I have run
into a problem that in the end leaves me with a DanglingReferenceException.
During a DeleteCommand a RemoveCommand is called to clean another Object
from references to the object to delete.
The RemoveCommand is doing an ownerList.containsAll(collection) call
from its prepare method which returns false, hence never executes.
It all boils down to an equals-call on AbstractCDOIDLong which tries to
compare a CDOObject (in TRANSIENT state) with a CDOID. Is it valid for a
feature-list of CDORevision to contain other things that CDOIDs?
This problem seems to exist for indexOf() and lastIndexOf() as well.
Best regards
/Claes
Stacktrace:
at
org.eclipse.emf.cdo.spi.common.id.AbstractCDOIDLong.equals(AbstractCDOIDLong.java:77)
at java.util.ArrayList.indexOf(ArrayList.java:216)
at java.util.ArrayList.contains(ArrayList.java:199)
at
org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.contains(BaseCDORevision.java:414)
at org.eclipse.emf.internal.cdo.CDOStore.contains(CDOStore.java:244)
at
org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateContains(EStoreEObjectImpl.java:227)
at
org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateContainsAll(EStoreEObjectImpl.java:235)
at
org.eclipse.emf.common.util.DelegatingEList.containsAll(DelegatingEList.java:125)
at
org.eclipse.emf.edit.command.RemoveCommand.prepare(RemoveCommand.java:248)
at
org.eclipse.emf.common.command.AbstractCommand.canExecute(AbstractCommand.java:114)
at
org.eclipse.emf.edit.command.AbstractOverrideableCommand.doCanExecute(AbstractOverrideableCommand.java:120)
at
org.eclipse.emf.edit.command.AbstractOverrideableCommand.canExecute(AbstractOverrideableCommand.java:113)
at
org.eclipse.emf.common.command.CompoundCommand.appendAndExecute(CompoundCommand.java:656)
Christophe Bouhier skrev 2011-10-19 12:20:
> Hi Eike,
>
> I don't know to be honest, at some point I suspected, that the domain
> would not be able to resolve the resource with the code here in the
> Remove command. But this would require more investigation. I will need
> to find time for this. For now, I have a workaround. BTW, I noticed that
> CDO also has specialized implementations of the .edit framework. Perhaps
> it's already addressed there..
>
>
> @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 &&
> ownerList.containsAll(collection) &&
> (owner == null || !domain.isReadOnly(owner.eResource()));
>
> return result;
> }
>
> Thanks for your support!
> Christophe
>
>
> On 19-10-11 11:35, Eike Stepper wrote:
>> Am 19.10.2011 09:08, schrieb Christophe Bouhier:
>>> Eike,
>>>
>>> I found the problem. The RemoveCommand for the Reference B->A was not
>>> "executable".
>>>
>>> RemoveCommand.create(domain, referencingEObject,
>>> eStructuralFeature, eObject)
>>>
>>> I have tried a similar case which is not a bidi reference (No
>>> EOpposite), and then the remove command works as expected.
>> I'm not very experienced with the edit framework because CDO mostly
>> operates on the model level. Does that mean your problem is either
>> solved or not CDO-related?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>
|
|
|
| Re: [CDO] dangling reference on deleted object. [message #741591 is a reply to message #741397] |
Wed, 19 October 2011 17:33 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 19-10-11 15:44, Claes Rosell wrote:
Hi Claes,
Well this sounds indeed very much like it.
Did you by change created a bug for this?
thank you, rgds Christophe
> Hi.
>
> This seems to be related to the problem that I had, evaluating CDO, last
> year. Something that I not yet have found time to finish.
>
> Here is an extract from the email I sent to this list back then. If
> these two problems are related, the following information might be
> useful to you.
>
> /Claes
>
> <--->
> I am currently using CDO 3.0 20100526-1334 (Helios RC2) and I have run
> into a problem that in the end leaves me with a DanglingReferenceException.
>
> During a DeleteCommand a RemoveCommand is called to clean another Object
> from references to the object to delete.
> The RemoveCommand is doing an ownerList.containsAll(collection) call
> from its prepare method which returns false, hence never executes.
>
> It all boils down to an equals-call on AbstractCDOIDLong which tries to
> compare a CDOObject (in TRANSIENT state) with a CDOID. Is it valid for a
> feature-list of CDORevision to contain other things that CDOIDs?
>
> This problem seems to exist for indexOf() and lastIndexOf() as well.
>
> Best regards
> /Claes
>
> Stacktrace:
>
> at
> org.eclipse.emf.cdo.spi.common.id.AbstractCDOIDLong.equals(AbstractCDOIDLong.java:77)
>
> at java.util.ArrayList.indexOf(ArrayList.java:216)
> at java.util.ArrayList.contains(ArrayList.java:199)
> at
> org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.contains(BaseCDORevision.java:414)
>
> at org.eclipse.emf.internal.cdo.CDOStore.contains(CDOStore.java:244)
> at
> org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateContains(EStoreEObjectImpl.java:227)
>
> at
> org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateContainsAll(EStoreEObjectImpl.java:235)
>
> at
> org.eclipse.emf.common.util.DelegatingEList.containsAll(DelegatingEList.java:125)
>
> at
> org.eclipse.emf.edit.command.RemoveCommand.prepare(RemoveCommand.java:248)
> at
> org.eclipse.emf.common.command.AbstractCommand.canExecute(AbstractCommand.java:114)
>
> at
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.doCanExecute(AbstractOverrideableCommand.java:120)
>
> at
> org.eclipse.emf.edit.command.AbstractOverrideableCommand.canExecute(AbstractOverrideableCommand.java:113)
>
> at
> org.eclipse.emf.common.command.CompoundCommand.appendAndExecute(CompoundCommand.java:656)
>
>
>
> Christophe Bouhier skrev 2011-10-19 12:20:
>> Hi Eike,
>>
>> I don't know to be honest, at some point I suspected, that the domain
>> would not be able to resolve the resource with the code here in the
>> Remove command. But this would require more investigation. I will need
>> to find time for this. For now, I have a workaround. BTW, I noticed that
>> CDO also has specialized implementations of the .edit framework. Perhaps
>> it's already addressed there..
>>
>>
>> @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 &&
>> ownerList.containsAll(collection) &&
>> (owner == null || !domain.isReadOnly(owner.eResource()));
>>
>> return result;
>> }
>>
>> Thanks for your support!
>> Christophe
>>
>>
>> On 19-10-11 11:35, Eike Stepper wrote:
>>> Am 19.10.2011 09:08, schrieb Christophe Bouhier:
>>>> Eike,
>>>>
>>>> I found the problem. The RemoveCommand for the Reference B->A was not
>>>> "executable".
>>>>
>>>> RemoveCommand.create(domain, referencingEObject,
>>>> eStructuralFeature, eObject)
>>>>
>>>> I have tried a similar case which is not a bidi reference (No
>>>> EOpposite), and then the remove command works as expected.
>>> I'm not very experienced with the edit framework because CDO mostly
>>> operates on the model level. Does that mean your problem is either
>>> solved or not CDO-related?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>
>
|
|
|
| Re: [CDO] dangling reference on deleted object. [message #742176 is a reply to message #741397] |
Thu, 20 October 2011 08:49 |
|
Am 19.10.2011 15:44, schrieb Claes Rosell:
> Hi.
>
> This seems to be related to the problem that I had, evaluating CDO, last year. Something that I not yet have found
> time to finish.
>
> Here is an extract from the email I sent to this list back then. If these two problems are related, the following
> information might be useful to you.
>
> /Claes
>
> <--->
> I am currently using CDO 3.0 20100526-1334 (Helios RC2) and I have run into a problem that in the end leaves me with a
> DanglingReferenceException.
>
> During a DeleteCommand a RemoveCommand is called to clean another Object from references to the object to delete.
> The RemoveCommand is doing an ownerList.containsAll(collection) call from its prepare method which returns false,
> hence never executes.
>
> It all boils down to an equals-call on AbstractCDOIDLong which tries to compare a CDOObject (in TRANSIENT state) with
> a CDOID.
Well, that sounds like bug 350987:
Revision compare does not consider EObject values in references
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350987
> Is it valid for a feature-list of CDORevision to contain other things that CDOIDs?
Yes, this usually happens in dirty local transactions when a referenced object doesn't have a CDOID, yet, or not
anymore. It's supposed to be either fixed (replaced by a CDOID at commit time).
>
> This problem seems to exist for indexOf() and lastIndexOf() as well.
We're currently discussing this issue within the team...
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Best regards
> /Claes
>
> Stacktrace:
>
> at org.eclipse.emf.cdo.spi.common.id.AbstractCDOIDLong.equals(AbstractCDOIDLong.java:77)
> at java.util.ArrayList.indexOf(ArrayList.java:216)
> at java.util.ArrayList.contains(ArrayList.java:199)
> at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.contains(BaseCDORevision.java:414)
> at org.eclipse.emf.internal.cdo.CDOStore.contains(CDOStore.java:244)
> at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateContains(EStoreEObjectImpl.java:227)
> at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateContainsAll(EStoreEObjectImpl.java:235)
> at org.eclipse.emf.common.util.DelegatingEList.containsAll(DelegatingEList.java:125)
> at org.eclipse.emf.edit.command.RemoveCommand.prepare(RemoveCommand.java:248)
> at org.eclipse.emf.common.command.AbstractCommand.canExecute(AbstractCommand.java:114)
> at org.eclipse.emf.edit.command.AbstractOverrideableCommand.doCanExecute(AbstractOverrideableCommand.java:120)
> at org.eclipse.emf.edit.command.AbstractOverrideableCommand.canExecute(AbstractOverrideableCommand.java:113)
> at org.eclipse.emf.common.command.CompoundCommand.appendAndExecute(CompoundCommand.java:656)
>
>
> Christophe Bouhier skrev 2011-10-19 12:20:
>> Hi Eike,
>>
>> I don't know to be honest, at some point I suspected, that the domain
>> would not be able to resolve the resource with the code here in the
>> Remove command. But this would require more investigation. I will need
>> to find time for this. For now, I have a workaround. BTW, I noticed that
>> CDO also has specialized implementations of the .edit framework. Perhaps
>> it's already addressed there..
>>
>>
>> @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 &&
>> ownerList.containsAll(collection) &&
>> (owner == null || !domain.isReadOnly(owner.eResource()));
>>
>> return result;
>> }
>>
>> Thanks for your support!
>> Christophe
>>
>>
>> On 19-10-11 11:35, Eike Stepper wrote:
>>> Am 19.10.2011 09:08, schrieb Christophe Bouhier:
>>>> Eike,
>>>>
>>>> I found the problem. The RemoveCommand for the Reference B->A was not
>>>> "executable".
>>>>
>>>> RemoveCommand.create(domain, referencingEObject,
>>>> eStructuralFeature, eObject)
>>>>
>>>> I have tried a similar case which is not a bidi reference (No
>>>> EOpposite), and then the remove command works as expected.
>>> I'm not very experienced with the edit framework because CDO mostly
>>> operates on the model level. Does that mean your problem is either
>>> solved or not CDO-related?
>>>
>>> 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
|
|
|
| Re: [CDO] dangling reference on deleted object. [message #742199 is a reply to message #741591] |
Thu, 20 October 2011 09:16 |
Claes Rosell
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
Hi.
I did open a bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=316273
However, I was not persuasive enough in my attempts to explain the
actual problem. Since then I have unfortunately had very little time to
experiment with CDO. I have not tested CDO4.0 at all.
Best regards
/Claes
Christophe Bouhier skrev 2011-10-19 19:33:
> On 19-10-11 15:44, Claes Rosell wrote:
>
> Hi Claes,
>
> Well this sounds indeed very much like it.
> Did you by change created a bug for this?
>
> thank you, rgds Christophe
>
>> Hi.
>>
>> This seems to be related to the problem that I had, evaluating CDO, last
>> year. Something that I not yet have found time to finish.
>>
>> Here is an extract from the email I sent to this list back then. If
>> these two problems are related, the following information might be
>> useful to you.
>>
>> /Claes
>>
>> <--->
>> I am currently using CDO 3.0 20100526-1334 (Helios RC2) and I have run
>> into a problem that in the end leaves me with a
>> DanglingReferenceException.
>>
>> During a DeleteCommand a RemoveCommand is called to clean another Object
>> from references to the object to delete.
>> The RemoveCommand is doing an ownerList.containsAll(collection) call
>> from its prepare method which returns false, hence never executes.
>>
>> It all boils down to an equals-call on AbstractCDOIDLong which tries to
>> compare a CDOObject (in TRANSIENT state) with a CDOID. Is it valid for a
>> feature-list of CDORevision to contain other things that CDOIDs?
>>
>> This problem seems to exist for indexOf() and lastIndexOf() as well.
>>
>> Best regards
>> /Claes
>>
>> Stacktrace:
>>
>> at
>> org.eclipse.emf.cdo.spi.common.id.AbstractCDOIDLong.equals(AbstractCDOIDLong.java:77)
>>
>>
>> at java.util.ArrayList.indexOf(ArrayList.java:216)
>> at java.util.ArrayList.contains(ArrayList.java:199)
>> at
>> org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.contains(BaseCDORevision.java:414)
>>
>>
>> at org.eclipse.emf.internal.cdo.CDOStore.contains(CDOStore.java:244)
>> at
>> org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateContains(EStoreEObjectImpl.java:227)
>>
>>
>> at
>> org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateContainsAll(EStoreEObjectImpl.java:235)
>>
>>
>> at
>> org.eclipse.emf.common.util.DelegatingEList.containsAll(DelegatingEList.java:125)
>>
>>
>> at
>> org.eclipse.emf.edit.command.RemoveCommand.prepare(RemoveCommand.java:248)
>>
>> at
>> org.eclipse.emf.common.command.AbstractCommand.canExecute(AbstractCommand.java:114)
>>
>>
>> at
>> org.eclipse.emf.edit.command.AbstractOverrideableCommand.doCanExecute(AbstractOverrideableCommand.java:120)
>>
>>
>> at
>> org.eclipse.emf.edit.command.AbstractOverrideableCommand.canExecute(AbstractOverrideableCommand.java:113)
>>
>>
>> at
>> org.eclipse.emf.common.command.CompoundCommand.appendAndExecute(CompoundCommand.java:656)
>>
>>
>>
>>
>> Christophe Bouhier skrev 2011-10-19 12:20:
>>> Hi Eike,
>>>
>>> I don't know to be honest, at some point I suspected, that the domain
>>> would not be able to resolve the resource with the code here in the
>>> Remove command. But this would require more investigation. I will need
>>> to find time for this. For now, I have a workaround. BTW, I noticed that
>>> CDO also has specialized implementations of the .edit framework. Perhaps
>>> it's already addressed there..
>>>
>>>
>>> @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 &&
>>> ownerList.containsAll(collection) &&
>>> (owner == null || !domain.isReadOnly(owner.eResource()));
>>>
>>> return result;
>>> }
>>>
>>> Thanks for your support!
>>> Christophe
>>>
>>>
>>> On 19-10-11 11:35, Eike Stepper wrote:
>>>> Am 19.10.2011 09:08, schrieb Christophe Bouhier:
>>>>> Eike,
>>>>>
>>>>> I found the problem. The RemoveCommand for the Reference B->A was not
>>>>> "executable".
>>>>>
>>>>> RemoveCommand.create(domain, referencingEObject,
>>>>> eStructuralFeature, eObject)
>>>>>
>>>>> I have tried a similar case which is not a bidi reference (No
>>>>> EOpposite), and then the remove command works as expected.
>>>> I'm not very experienced with the edit framework because CDO mostly
>>>> operates on the model level. Does that mean your problem is either
>>>> solved or not CDO-related?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://www.esc-net.de
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>
>>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 15:52:17 GMT 2024
Powered by FUDForum. Page generated in 0.03812 seconds |
] 
Search
Help
Register
Login
Home
