Hi again,

Henrik Berg wrote:
Mahler Thomas <[EMAIL PROTECTED]> writes:


Hi again Henrik,


-----Original Message-----
From: Henrik Berg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 9:53 AM
To: [EMAIL PROTECTED]
Subject: Removing objects from collections...again


For some reason, suddenly the RemovalAwareCollection-stuff started
working again here... Have no idea what's happened, I hadn't looked
at this for some time, and then, today, everything seems to work just
fine.

We call this feature "telekinetic software update" (TM) :-)



Hm, this reminds me of Orwell's 1984...


There was some bug in one of the classes.  The developers, reluctant
to admit their mistakes, hacked into all the computers in the world
where OJB was installed, and replaced the code with the new, corrected
code.  I suppose now you're going to scan through the mailing-list
archives, deleting every reference to the
RemovalAwareCollection-problems.  Clever.


:-)


Remember the black cat crossing the floor twice in MATRIX ?
It was the "telekinetic software update" (TM) in action!



Anyone else still having problems with RemovalAwareCollections?

Now what I need, is some Collection-class that removes the removed
objects, but lets them stay in the database, just sets their foreign
keys to 0/null or something, so that they don't reappear in the
collection next time it loads from the database.

Any possibility I could make this happen?

Yes, that's possible. For example the ODMG collection DListImpl works in this way.



I haven't looked much indo ODMG yet. Can I use DListImpl with the
PersistentBroker API?

No it only makes sense to use them with ODMG.



It is also possible to simulate this with using a m:n mapping with an
intermediary table.
you just configure it so that only the entries from the intermediary table
get deleted but not the refernced entries.


OK, suppose this is the way I'll do it.

It's the cleanest solution. Some O/R experts even recommed to always use intermediary table even if you know that you are only have a 1:n association.





Of course you can also use the trick to set the FK's to 0.


Doesn't sound very clean.

I agree!


Can the object determine the FK-field at
run-time?

yes, OJB automatically maintains foreign key attributes.


cheers,
Thomas


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



Reply via email to