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: [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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
