Yes, Jakob gets the point.
As far as I understood, if I don't specify the collection-class, OJB will
use RemovalAwareCollection.
Being as is, when I remove an object from the intermediary collection, the N
object should be deleted from the N table when we store the M object only
when auto-delete feature is true.
If the collection-class is not RemovalAware, then there is no problem.
Things should be as they had from months. Or OJB should not use
RemovalAwareCollection as default for M:N non-decomposible.
That's about my hack is.
I undertand Thomas points about my configuration. He is right. Maybe the
only thing that should be fixed is documentation. Maybe I'm doing some kind
of biggest-than-ever mistake. Check what a kind of collection-descriptor I
use here:
<collection-descriptor
name="perfis"
element-class-ref="br.com.mgr.beans.PerfilPessoaFJBean"
indirection-table="RL_PESSOA_TIPOPESSOA"
proxy="true"
auto-retrieve="true"
auto-update="false"
auto-delete="false">
<fk-pointing-to-this-class column="CO_PESSOA"/>
<fk-pointing-to-element-class column="CO_TIPO_PESSOA"/>
</collection-descriptor>
where perfis is related to setPerfis and getPerfis:
public class Pessoa {
private List perfis;
public void setPerfis( List p ) {this.perfis=p;}
public List getPerfis( ) {return this.perfis;}
}
Just it!
Now, if I delete an element as in getPerfis().remove(0) and then
broker.store( pessoa ), the real object is not anymore deleted.
And if I put auto-delete="true" and issue getPerfis().remove(0) and then
broker.store( pessoa ), the indirection record and the real object is
deleted.
May be this a my mis-interpretation? Why M:N documentation don't say
anything about "use ManageableArrayList if you wish your objects not being
deleted from the N side"? And that RemovalAwareCollection is the default
collection if you don't specify one?
Excuse-me if all this thread is my mistake, but I'm very happy because after
fix tomorrow, all my app came to a stable and clear behaviour...
Thanks,
Edson Richter
----- Original Message -----
From: "Jakob Braeuchi" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Thursday, June 26, 2003 5:27 PM
Subject: Re: SOLUTION for M:N never delete or always delete, no matter
auto-delete="true" or auto-delete="false"
hi thomas,
so my testcases are wrong as well :( (it's probably too hot here)
to clarify this issue:
- when the collection IS removal aware the n side is ALWAYS deleted when
removed from the collection (not matter of the auto-xxx settings).
- when the collection IS NOT removal aware the n side is NEVER deleted.
is this how it should be ?
jakob
Thomas Mahler wrote:
> Hi again,
>
> Edson Carlos Ericksson Richter wrote:
>
>> (this is a real long mail, but I've made a long research. The first
>> part is
>> the reason I started to research, the second is explain why this
>> occur. The
>> third is a suggestion of how can we correct).
>>
>> FIRST PART:
>> Ok. To avoid the problem related to OJB always using
>> RemovalAwareCollection,
>> I put my beans to work as
>>
>> public class A {
>> private ArrayList myColl = new ArrayList();
>>
>> public void setMyCollection( List collection ) { this.myColl.clear;
>> this.myColl.addAll( collection ); }
>> public List getMyCollection( ) {return this.myColl;}
>> }
>>
>> Doing this, I'm converting from RemovalAwareCollection to ArrayList.
>> Fine.
>>
>
> why do you type your attribute as ArrayList? if you just have "List
> myColl = ..." it would safe a lot of problems...
>
> If you really wnat to use ARrayList just use
> collection-class="ManageableArrayList" in the collection-descriptor.
> This will avoid the addAll call!
>
>> Now suppose that I want auto-delete="true". Then I
>>
>> getMyCollection().remove(0);
>>
>> and then persist the object. Theorically, OJB should delete the
>> object from
>> indirection table AND the referenced table (the N side, ok?).
>
>
> No! entries are deleted only from the indirection table! objects are
> only deleted automatically from the N side if you use a
> RemovalAwareCollection.
>
> This not
>
>> occur. OJB deletes only from indirection table (the auto-delete
>> option makes
>> no difference).
>
>
> auto-delete does not change any behaviour of broker.store(...). It is
> meant to change behaviour of broker.delete(...) calls !
>
>>
>> If I change the code to
>>
>> public class A {
>> private List myColl;
>>
>> public void setMyCollection( List collection ) {
>> this.myColl=collection; }
>> public List getMyCollection( ) {return this.myColl;}
>> }
>>
>> then it works (because the collection passed to setter is
>> RemovalAwareCollection).
>
>
> as explained above.
>
>> BUT, if I put auto-delete="false", then OJB still
>> delete the indirection table AND the referenced table (again, the
>> auto-delete option makes no difference).
>
>
> as expalined above.
>
>> SECOND PART:
>> To the facts: since OJB is using RemovalAwareCollection, after the
>> correct
>> treatment for M:N non-decomposable queries (that my debugging show
>> that it
>> is working like a charm), the following code is being executed:
>>
>> // invoke callback on collection
>> if (col instanceof ManageableCollection)
>> {
>> ((ManageableCollection) col).afterStore(this);
>> }
>>
>> That is deleting the real objects, even if auto-delete="false".
>
>
> if you don't want delete semantics just use
> collection-class="ManageableArrayList" in the collection-descriptor.
>
>>
>> THIRD PART:
>> The method deleteMtoNImplementor(...) should reset the
>> "allObjectsToBeRemoved" in RemovalAwareCollection if the auto-delete
>> option
>> is set to false. What do you think?
>
>
> I don't think so, because auto-delete is not used during store(..).
>
> I think you problems can be solved by simple configuration settings. I
> did not see any errors in the mentioned OJB code. So I don't feel that
> the existing behaviour should be changed.
>
> cheers,
> Thomas
>
>> Something like create a RemovalAware
>> interface. Make all classes (RemovalAwareCollection, and
>> RemovalAwareList in
>> my case) implement it. Then do
>>
>> public interface RemovalAware {
>>
>> public void resetDeleted();
>> }
>>
>> The resetDelete method implementation is just
>>
>> public void resetDeleted( ) {
>> allObjectsToBeRemoved.clear();
>> }
>>
>>
>> and then change PersistentBrokerImpl to
>>
>> currentMtoNKeys = getMtoNImplementor(cds, obj);
>> // delete unused m:n implementors
>> deleteMtoNImplementor(cds, obj, (Collection)col,
>> currentMtoNKeys);
>>
>> if( col instanceof ManageableCollection &&
>> !cds.getCascadeDelete() ) {
>> Collection testCol;
>> if( col instanceof CollectionProxy ) {
>> testCol = ( ( CollectionProxy )col ).getData();
>> } else {
>> testCol = ( Collection )col;
>> }
>>
>> if( testCol instanceof RemovalAware ) {
>> ( ( RemovalAware )testCol ).resetDeleted();
>> }
>> }
>>
>> This make M:N suff work working. I'm using CVS HEAD.
>>
>> Thanks for your patience.
>>
>> Edson Richter
>>
>>
>>
>>
>> ---
>> Outgoing mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.493 / Virus Database: 292 - Release Date: 25/6/2003
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 25/6/2003
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
