This looks good, but I’m not sure we want to remove the cascade deletion. I feel it is fine if we do soft deletion; if the user really wants the record to be actually gone, the ti should be gone too. See discussion in linked issue.

soft deletion

@uranusjr I have just added soft deletion and added back cascade deletion. Please re-review.

But now that I think about it. Task instances are your single source of truth for what actually ran, when and with what outcome. If you delete the serialised-DAG (or its version), you wipe out every TaskInstance that pointed at it. That means no more execution history or retry state for those runs. Is this the right behaviour for the user?

Just closing this for now to prevent accidental merge --- I talked with @sunank200 and we are thinking that the best course of action is to simply change the ondelete behavior to be "on delete restrict" because it's always assumed that this value will be populated and this will simply prevent unintentional deletion of TI rows

Other notes: if we don't change the ondelete behavior, when adding soft delete does not actually solve the problem (risk of accidental TI deletion) becasue it's purely a software concept. So the question of whether we need soft deletes is really a separate issue.

And, I am not aware of any reason we actually want soft deletes or what the point of it would be or what the user interface would be.

So that's why we think, let's just add restrict.