Re: Foreign Key Constraint Deletion Order

On Tue, 20 Nov 2001 cnliou(at)eurosport(dot)com wrote:

> This is really a pain though it works.
>
> Since delete from PurchaseMaster and PurchaseDetail
> are both possible, two subtraction trigger functions
> must be written for PurchaseMaster and
> PurchaseDetail, respectively.
>
> It also seems unwise not to use the
> powerful-but-easy-to-use RI capability (on delete
> cascade on update cascade) but to implement it with
> my own trigger to be fired by PurchaseMaster.

Yeah, there's also some locking gotchas involved
so while the RI stuff isn't nearly perfect it's
probably a good idea to stick with it unless
you're running one of the problem cases.

> If the delete was always done on PurchaseDetail
> before PurchaseMaster, then one subtraction function
> for PurchaseDetail along with the RI would settle
> down everything.
>
> Am I asking for too much, or RI and triggers were not
> designed for operations like this example in the
> first place?

For the particular case you're looking for I don't think
so. It sounds like it'd make sense, but I don't think
it'd fit the spec wording (given that we've been arguing
how far after the deletion that the cascade occurs, I
don't think anyone's argued for before the deletion).