db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tino Schöllhorn <t.schoellh...@plattform-gmbh.de>
Subject Re: Bug and proposed patch
Date Sun, 12 Dec 2004 17:45:32 GMT
Hi Jakab,

yes, you are right. The Collection is actually a 1:N-Collection. I just 
looked at the source-code of 
CollectionTest#testDeleteMainObjectWithOneToNRelation and in this test 
the references are deleted manually. This is the main difference in my 
point of view. The same with CollectionTest#testDeleteCollection. So I 
think my described use-case is not testd with those tests.

Tino

Jakob Braeuchi wrote:
> hi tino,
> 
> just to make sure: your test-case is actually a 1:n collection.
> 
> how does your test differ from CollectionTest#testDeleteCollection or 
> CollectionTest#testDeleteMainObjectWithOneToNRelation ?
> 
> in these testcases a main-object is deleted with it's associated 1:n 
> children (when auto-delete = object).
> 
> jakob
> 
> Tino Schöllhorn schrieb:
> 
>> Hi,
>>
>> yesterday I posted a problem in the user-list (Deleting Main-Object 
>> and its association-objects). Currently there are no answers for this 
>> message. I looked further at the code of OJB. The method which is 
>> interesting at this point is 
>> PersistenceBrokerImpl.deleteCollections(Object, List).
>>
>> Suppose you have the following case: Persons work at Projects with an 
>> associated Role. Now if you are deleting a Person-Object or a 
>> Project-Object you want to delete the corresponding Role-objects as well.
>>
>> Normally one can achieve that with *auto-delete=object* at the 
>> collections for the role-objects. But the current implementation does 
>> not work here correctly. If one has 3 or more role objects to be 
>> handled one gets a ConcurrentModificationException, like this one 
>> (line numbers have changed because of some change from me):
>>
>> java.util.ConcurrentModificationException
>>     at 
>> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
>>     at java.util.AbstractList$Itr.next(AbstractList.java:419)
>>     at 
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.deleteCollections(PersistenceBrokerImpl.java:701)

>>
>>     at 
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.doDelete(PersistenceBrokerImpl.java:514)

>>
>>     at 
>> org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java:466)

>>
>>     at 
>> org.apache.ojb.broker.core.DelegatingPersistenceBroker.delete(DelegatingPersistenceBroker.java:170)

>>
>>     at 
>> org.apache.ojb.broker.core.DelegatingPersistenceBroker.delete(DelegatingPersistenceBroker.java:170)

>>
>>     at kos.generator.DataObject.delete(DataObject.java:106)
>>     at 
>> kos.intranet2.sandbox.DeletePersonTest.runTest(DeletePersonTest.java:64)
>>     at 
>> kos.intranet2.sandbox.DeletePersonTest.main(DeletePersonTest.java:98)
>>
>>
>> The current implementation looks like:
>>
>> if (cds.getCascadingDelete() == 
>> bjectReferenceDescriptor.CASCADE_OBJECT) {
>>     Object col = cds.getPersistentField().get(obj);
>>         if (col != null)
>>         {
>>             while (colIterator.hasNext())
>>                 {
>>                     doDelete(colIterator.next());
>>                 }
>>         }
>> }
>>
>> And the ConcurrentModificationException is thrown at the call of 
>> doDelete.
>>
>> If a am using OJB correctly this use-case should work. So I propose 
>> the following (but perhaps imperformant and inelegant) patch: The idea 
>> is simple. Instead of deleting the object immediately from its 
>> origin-collection, copy the elements to another collection an use this 
>> for deleting.
>>
>> if (cds.getCascadingDelete() == 
>> bjectReferenceDescriptor.CASCADE_OBJECT) {
>>     Object col = cds.getPersistentField().get(obj);
>>         if (col != null)
>>         {
>>         // Inelegant and brutal. but it works
>>          Collection c = new java.util.ArrayList();
>>                  while (colIterator.hasNext()) {
>>                      c.add(colIterator.next());
>>                  }
>>                  Iterator j = c.iterator();
>>                  while (j.hasNext())
>>                  {
>>                      doDelete(j.next());
>>                  }
>>         }
>> }
>>
>> So do you think you could apply this patch - or am I mistaken and I am 
>> using OJB in a wrong way?
>>
>> With regards
>> Tino
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message