>> In all cases, and given the typical profile of a machine hosting your DB,
>> keeping a row even if it's not used for a while is probably preferable to
>> deleting it and inserting it again later.
You hit the nail on the head. Why did they delete the independent object?
I am still looking for a real scenario where this is useful. Something like
"I'm building an eCommerce system and I'm deleting the invoice independent
objects but keeping the line item dependent objects because I need to know
what people ordered, but I don't need to know when they ordered it or who
ordered it."
>From the point of referential integrity within the db keeping these orphan
rows around doesn't feel all that great. I've spent enough of my life
writing programs to find and clean out orphan rows, building applications to
create them somehow doesn't really feel like the way to go...
The spec says that the container won't automatically delete these orphan
rows, it doesn't say that the application cannot delete them as it sees fit.
I'm sure there are draw backs to cascade delete within the tool, I was more
trying to deal with logical 'cascade delete' than any specific
implementation of it.
Cheers
Jay Walters
-----Original Message-----
From: Cedric Beust [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 01, 2000 6:27 PM
To: jBoss Developer
Subject: RE: [jBoss-Dev] EJB 2.0 spec question
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jay Walters
> I'm having a hard time visualizing a case where you want the behaviour
which
> the spec talks about in terms of detachment, no cascade delete and keep
> unnavigable rows around.
Several possible scenarios:
- They might be unnavigable only for a limited period of time, waiting to be
incorporated in different relationships later on.
- Non-EJB processes might want to use them.
- They can still be found through EJB-QL, so they're not worthless.
In all cases, and given the typical profile of a machine hosting your DB,
keeping a row even if it's not used for a while is probably preferable to
deleting it and inserting it again later.
On a separate issue, cascade-delete is a very powerful (and thus dangerous)
weapon. It can have disastrous effects if you have misconfigured your
relations. Not mentioning the impact on performance when your cascading
delete
starts hitting 1-1 relationships. It used to be the default, we convinced
Sun
it shouldn't be, we're certainly glad they agreed :-)
--
Cedric
