Community
Participate
Working Groups
Build Identifier: 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? Reproducible: Always
Created attachment 171536 [details] Project containing a test case for the bug.
A test case as a subclass of AbstractCDOTest would have been nicer ;-) After adjusting things like the connector description, repository name, etc. I could run the app and it terminated with: org.eclipse.emf.cdo.util.CommitException: org.eclipse.emf.cdo.util.DanglingReferenceException: The object "LinkBetween?(org.eclipse.cdo.testmodel.impl.LinkBetweenImpl)" is not contained in a resource at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:931) at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:942) at org.eclipse.cdo.testcase.Application.start(Application.java:97) For me that looks perfectly okay, because you're removing the LinkBetween object from the "links" containment list (i.e. you detach it) while it is still cross-referenced in the opposite direction. I'm closing this as WORKSFORME, but please feel free to reopen and describe in more detail what you think is wrong and how you expect it to behave. BTW. in rare cases a revision can contain target objects rather than their CDOIDs. This can only happen in dirty local transactions and gets automatically fixed when committing this transaction. This is meant to be a performance optimization and should not lead to problems.
I am reopening this bug. :-) I think that I was not clear enough about what, in my opinion, the problem is. In the test-app I do remove the LinkBetween object from the resource but I also try to remove the cross-reference in the opposite direction (row 92 & 93), which fails (row 92). This is in my opinion a bug. Since the reference exists in the BOBJECT__REFERRING_LINKS list I should be able to remove it. I am not completely sure, but I think that an isolated EMF-Edit DeleteCommand operation on LinkBetween would fail on this test model as well. Since the behaviour of DeleteCommand is to first detach the object from the model and after that remove the references from isMany() features and set !isMany() features to null.
I've added Bugzilla_316273_Test with two test cases and they all pass properly. I may still have misunderstood the problem or written a wrong test case. In this case please reopen this bugzilla and attach a test case like the mentioned one that reproduces the problem.
Hi, I would like to re-open the bug as I have the exact same problem. As Claes wrote earlier, the Remove command is not executed because the ownerList equality method which returns unequal for a detached CDOObject. So basically the EMF higher level Delete command is not compatible with CDO, even though CDO itself could be doing the right thing. It is not compatible because the prepare() in RemoveCommand should really return true in the sequence of activities of the the DeleteCommand. 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; } In our failing case the collection contains the object in state TRANSIENT (As the DeleteCommand has detached it before removing the references to it), why should it not be part of the EREF collection, even in state TRANSIENT? It seems so ambiguous to later throw a Danglingref exception when committing. rgds Christophe
I'm willing to reconsider my initial arguments ;-) But I'm currently facing a high work load. Is it possible that you provide me with a test case (on top of our cool test bed, AbstractCDOTest)? That would make it more likely that I can address this issue soon.
(In reply to comment #6) > I'm willing to reconsider my initial arguments ;-) > > But I'm currently facing a high work load. Is it possible that you provide me > with a test case (on top of our cool test bed, AbstractCDOTest)? That would > make it more likely that I can address this issue soon. Eike, yes I will for this bug and a couple more which I promised. I am myself facing a delivery schedule which is already overdue, so I will need a quiet sunday morning to prepare my workspace for your test bed).
Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems. Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!!
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
THe applied test (although I can see no proper assertions) seems to pass nicely. Probably the problem has been fixed via some other bug during the years. Please reopen this bug if you feel a need.
Available in R20130613-1157 (4.2)
