Forum OpenACS Development: Re: Clean delete of packages

Posted by Peter Marklund on
I am changing the package delete page in the APM UI so that it unmounts and deletes all instances before deleting the package. That way, by using APM Tcl callbacks we are able to cleanly delete workflow and bug tracker from the APM UI.

IMHO permissions should cascade, or if we don't want to cascade, why don't we delete them in acs_object__delete? Analogously I just set up lang_message_keys to cascade from package_key.

I think non-cascading constraints are a major headache and I also think they can cause serious problems. What if package A sets a constraint on an object in package B. When package B tries to delete its object it fails because package A (that package B has no knowledge of) has it referenced. Isn't this just plain wrong? I think all composite relationships should be cascading constraints (permissions are a perfect example, they can't exist without the party, privilege, or object that they are made up of).

The only thing that could convince me that cascading is bad is the warning I got from Jeff Davis that cascading can cause locking issues or other problems. I don't understand yet why that would happen but if somebody can explain it to me or even better show how it happens in OpenACS in practice I would be more than willing to change my mind.

Posted by Tilmann Singer on

<blockquote> why don't we delete them in acs_object__delete?

That's exactly what's happening now. The reason not to use cascade in this case was just that it was simpler because it doesn't require complicated upgrade scripts, just reloading the pl/sql (plpgsql) code.

The reason not to use cascade in many other cases is one most strongly made by Dirk (on irc, maybe also somewhere in this forum), that deletion of data in general is a bad idea, and there is no need to jump trough loops to enable it everywhere in the toolkit. The foreign key constraints are thus a good thing, because they prevent you from deleting data that is referenced from somewhere else. A good example for this is the user object - you almost certainly wouldn't want a system that deletes on cascade all objects a user has references to, directly because he created them or somehow indirectly. We might just have to accept that in a highly referenced data like in OpenACS things like users are just not deletable.