Edson Carlos Ericksson Richter wrote:
I don't think so.i explicitely used a vector (not removal aware) when creating the object.
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
don't know why, but is it a big problem for you. i mean except from ignoring auto-delete OFF ?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.
yes please.
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
jakob
----- Original Message ----- From: "Jakob Braeuchi" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
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:
RemovalAwareCollection,(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
I put my beans to work asmakes
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
no difference).this.myColl=collection; }
If I change the code to
public class A { private List myColl;
public void setMyCollection( List collection ) {
inpublic 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
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]
--- 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]
