Re: delete cascade

On Apr 18, 10:22 am, paul c <toledobythe..._at_oohay.ac> wrote:
> David BL wrote:
> > On Apr 18, 9:31 am, paul c <toledobythe..._at_oohay.ac> wrote:
>
> >>Bob Badour wrote:
>
> >>>...
> >>>I am still lost. When does it delete? When does it not delete?
>
> >>Oh, I was assuming a delete is not possible if it would cause the
> >>constraint to be violated. Just what would happen would depend on
> >>implementation, personally I'd prefer a result of "false" but I guess
> >>many people prefer exceptions, just as many prefer "delete cascade".
>
> >>p
>
> > That's not consistent with your OP where you say
>
> > ...Ie., why shouldn't delete always mean so-called "cascade"?
>
> > It seems to me there is only one logical constraint
>
> > item exists => inv exists
> > ...
>
> As I saw it, Bob introduced another constraint, which I could call "NOT
> CASCADES" and I tried to form it in an unconventional way with <AND> and
> <OR> TTM equivalents, in other words in my view given Bob's constraint,
> both relations have constraints.

It seems to me that a "NOT CASCADES" constraint can't be expressed using a predicate defined on the DB state. Instead it is predicated on two consecutive DB states (in order to constrain allowable transitions).

[snip] Received on Wed Apr 18 2007 - 16:02:11 CEST