You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Edson Carlos Ericksson Richter <ed...@mgrinformatica.com.br> on 2003/06/26 17:36:10 UTC
SOLUTION for M:N never delete or always delete, no matter auto-delete="true" or auto-delete="false"
(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.
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?). This not
occur. OJB deletes only from indirection table (the auto-delete option makes
no difference).
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). 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).
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".
THIRD PART:
The method deleteMtoNImplementor(...) should reset the
"allObjectsToBeRemoved" in RemovalAwareCollection if the auto-delete option
is set to false. What do you think? 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
Re: SOLUTION for M:N never delete or always delete, no matter auto-delete="true"
or auto-delete="false"
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi edson,
i changed the testcases. now we have
auto-delete ON RemovalAware (ok)
auto-delete ON not RemovalAware (fail)
auto-delete OFF RemovalAware (fail)
auto-delete OFF not RemovalAware (ok)
i could not find col.afterStore() when you check cascadeDelete ?
jakob
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.
>
>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?). This not
>occur. OJB deletes only from indirection table (the auto-delete option makes
>no difference).
>
>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). 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).
>
>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".
>
>THIRD PART:
>The method deleteMtoNImplementor(...) should reset the
>"allObjectsToBeRemoved" in RemovalAwareCollection if the auto-delete option
>is set to false. What do you think? 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: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
Re: SOLUTION for M:N never delete or always delete, no matter auto-delete="true"
or auto-delete="false"
Posted by Thomas Mahler <th...@web.de>.
Hi Jakob,
Jakob Braeuchi wrote:
> 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.
correct!
>
> is this how it should be ?
I think so.
before the introduction of RemovalAwareCollections
irems that were deleted from colections did not get deleted during
broker.store().
With RemovalAwareCollection we are now able to provide this semantics in
the PB layer.
auto-delete should not have any impact on broker.store() semantics!
as usual
my 2c
Thomas
> 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: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: SOLUTION for M:N never delete or always delete, no matter auto-delete="true" or auto-delete="false"
Posted by Edson Carlos Ericksson Richter <ed...@mgrinformatica.com.br>.
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" <jb...@gmx.ch>
To: "OJB Users List" <oj...@db.apache.org>
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: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---
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
Re: SOLUTION for M:N never delete or always delete, no matter auto-delete="true"
or auto-delete="false"
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: SOLUTION for M:N never delete or always delete, no matter auto-delete="true"
or auto-delete="false"
Posted by Thomas Mahler <th...@web.de>.
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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: SOLUTION for M:N never delete or always delete, no matter auto-delete="true"
or auto-delete="false"
Posted by Jakob Braeuchi <jb...@gmx.ch>.
Edson Carlos Ericksson Richter wrote:
>I don't think so.
>
>First of all, OJB is always using RemovalAwareCollection if I don't specify
>collection-class (I don't know why).
>Since RemovalAwareCollection has a call to afterStore, the object is always
>removed. I'm working a months with this problem, and trying to fix it. But
>
i explicitely used a vector (not removal aware) when creating the object.
>only with latest changes by thma (get by CVS HEAD) to make RemovalAware full
>working, I get into the light, and with the changes I've done, the
>MtoNTest#testDeletionFromBothTables and
>MtoNTest#testDeletionFromIntermediaryTable should (I've not tested, only
>with my own code) works fine.
>
>I wan't to enphatize two points:
>
>1) cvs HEAD doesn't accept Collection subclasses anymore (except the ones
>that are Manageable). If you try to put a collection-class =
>"java.util.ArrayList" or anything else, you'll get ClassCastException due a
>ManageableCollection cast.
>
don't know why, but is it a big problem for you. i mean except from
ignoring auto-delete OFF ?
>
>2) cvs HEAD with changes I've done make OJB M:N mapping work like expected,
>with or without proxies, and not ignoring the
>auto-delete=true/auto-delete=false.
>
>If you have some time, try the junit tests (specially the ones related to
>M:N) with changes proposed... I can even send you the changed files, if you
>wish.
>
yes please.
>
>Is very important to me that OJB work fine with proxies and the M:N stuff.
>This is the reason I'm so boring about it...
>
>
>Best regards,
>
>Edson Richter
>
>
jakob
>
>----- Original Message -----
>From: "Jakob Braeuchi" <jb...@gmx.ch>
>To: "OJB Users List" <oj...@db.apache.org>
>Sent: Thursday, June 26, 2003 4:28 PM
>Subject: Re: SOLUTION for M:N never delete or always delete, no matter
>auto-delete="true" or auto-delete="false"
>
>
>hi edson,
>
>please have a look at the test case MtoNTest#testDeletionFromBothTables
>(auto-delete ON)
>and MtoNTest#testDeletionFromIntermediaryTable (auto-delete OFF).
>
>the first one fails because ojb only deletes from intermediary table.
>collection is not removal aware.
>
>
>jakob
>
>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.
>>
>>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?). This not
>>occur. OJB deletes only from indirection table (the auto-delete option
>>
>>
>makes
>
>
>>no difference).
>>
>>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). 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).
>>
>>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".
>>
>>THIRD PART:
>>The method deleteMtoNImplementor(...) should reset the
>>"allObjectsToBeRemoved" in RemovalAwareCollection if the auto-delete option
>>is set to false. What do you think? 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: ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
>---
>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: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
Re: SOLUTION for M:N never delete or always delete, no matter auto-delete="true" or auto-delete="false"
Posted by Edson Carlos Ericksson Richter <ed...@mgrinformatica.com.br>.
I don't think so.
First of all, OJB is always using RemovalAwareCollection if I don't specify
collection-class (I don't know why).
Since RemovalAwareCollection has a call to afterStore, the object is always
removed. I'm working a months with this problem, and trying to fix it. But
only with latest changes by thma (get by CVS HEAD) to make RemovalAware full
working, I get into the light, and with the changes I've done, the
MtoNTest#testDeletionFromBothTables and
MtoNTest#testDeletionFromIntermediaryTable should (I've not tested, only
with my own code) works fine.
I wan't to enphatize two points:
1) cvs HEAD doesn't accept Collection subclasses anymore (except the ones
that are Manageable). If you try to put a collection-class =
"java.util.ArrayList" or anything else, you'll get ClassCastException due a
ManageableCollection cast.
2) cvs HEAD with changes I've done make OJB M:N mapping work like expected,
with or without proxies, and not ignoring the
auto-delete=true/auto-delete=false.
If you have some time, try the junit tests (specially the ones related to
M:N) with changes proposed... I can even send you the changed files, if you
wish.
Is very important to me that OJB work fine with proxies and the M:N stuff.
This is the reason I'm so boring about it...
Best regards,
Edson Richter
----- Original Message -----
From: "Jakob Braeuchi" <jb...@gmx.ch>
To: "OJB Users List" <oj...@db.apache.org>
Sent: Thursday, June 26, 2003 4:28 PM
Subject: Re: SOLUTION for M:N never delete or always delete, no matter
auto-delete="true" or auto-delete="false"
hi edson,
please have a look at the test case MtoNTest#testDeletionFromBothTables
(auto-delete ON)
and MtoNTest#testDeletionFromIntermediaryTable (auto-delete OFF).
the first one fails because ojb only deletes from intermediary table.
collection is not removal aware.
jakob
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.
>
>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?). This not
>occur. OJB deletes only from indirection table (the auto-delete option
makes
>no difference).
>
>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). 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).
>
>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".
>
>THIRD PART:
>The method deleteMtoNImplementor(...) should reset the
>"allObjectsToBeRemoved" in RemovalAwareCollection if the auto-delete option
>is set to false. What do you think? 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: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---
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
Re: SOLUTION for M:N never delete or always delete, no matter auto-delete="true"
or auto-delete="false"
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi edson,
please have a look at the test case MtoNTest#testDeletionFromBothTables
(auto-delete ON)
and MtoNTest#testDeletionFromIntermediaryTable (auto-delete OFF).
the first one fails because ojb only deletes from intermediary table.
collection is not removal aware.
jakob
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.
>
>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?). This not
>occur. OJB deletes only from indirection table (the auto-delete option makes
>no difference).
>
>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). 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).
>
>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".
>
>THIRD PART:
>The method deleteMtoNImplementor(...) should reset the
>"allObjectsToBeRemoved" in RemovalAwareCollection if the auto-delete option
>is set to false. What do you think? 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: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>