Hello!

we came across this bug in july: when deleting an element from a
collection which is an m:n relation then the element itself gets deleted.
we found this mail back then and deployed that simple fix which seems to
work fine. back then we were using 1.0 rc3.

a few days ago I upgraded to 1.0 rc4 (because of the performance increase
mainly) just to find out that this bug still seems to be there. now I
wanted to ask if we are doing something wrong, if someones already working
on that bug or if it has just been overlooked because Thomas wrote that
the code is no longer there. I checked rc4 and have seen that code, just
the line numbers shifted a little...


greetings,
Nils


Thomas Mahler wrote:
>Hi Edson,
>
>I've checked in a patch to fix CollectionProxy (and ListProxy behaviour)
>and also patches to the M:N stuff this week.
>
>The code you refer to is no longer there (at least I didn't find it).
>please check the latest version from CVS if you still think there are
>problems.
>
>I'm now pretty confident we got everything right. I added several
>additional testcases and they all pass.
>
>cheers,
>Thomas
>
>
>Edson Carlos Ericksson Richter wrote:
>>
>>    Hi!
>>
>>Debugging again the M:N relationships, so we can work as expected with
>>proxies I've found the following bug (line 815, PersistenceBrokerImpl)
>>that make an Item be deleted even if we set auto-delete,
>>auto-update=false
>>in non-decomposible:
>>
>>
>>                if( col instanceof ManageableCollection)
>>                {
>>                    ((ManageableCollection) col).afterStore(this);
>>                }
>>
>>
>>    it should not be (but auto-update == auto-delete)
>>
>>                if( col instanceof ManageableCollection)
>>                {
>>                  if( !cds.isMtoNRelation() || ( cds.getCascadeDelete()
>>                  ||
>>cds.getCascadeStore() ) )
>>                    ((ManageableCollection) col).afterStore(this);
>>                }
>>
>>
>>    ???
>>
>>Or we should specify in collection descriptor explicit that this
>>collection is not ManageableCollection (appear that by default the
>>collection is RemovalAwareCollection if we don't specify anything).
>>
>>
>>    Thanks,
>>
>>    Edson Richter
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to