Re: Cascading delete issues

[prev] [thread] [next] [Date index for 2005/02/20]

In the dim and distant past, Tim Bunce wrote:
> I think the on-delete behaviour should be defined with the relationship.
> In other words has_many() should let you specify on-delete actions like
> cascade, restrict, set-null. That would match the behaviour of
> databases, which allow on-delete actions to be associated with
> foreign-key relationships.
> CD->has_many('tracks', 'Track' => 'cd', { on_delete => 'restrict' });

I've finally implemented this. However, I've done it in a manner that
lets anyone write their own strategies for what they want to happen
here.

The default implicit behaviour is still:
  CD->has_many(tracks => 'Track', { cascade => 'Delete' });

But you can also say:
  CD->has_many(tracks => 'Track', { cascade => 'Fail' });
to throw an error if there are any tracks left hanging.

Or even:
  CD->has_many(tracks => 'Track', { cascade => 'None' });
to allow the creation of these orphans.

These all delegate to the relevant Class::DBI::Cascade::Delete/Fail/None
object, and allow you to create your own:

  CD->has_many(tracks => 'Track', { cascade => 'MyDBI::Cascade::Nullify' });

This means the old, undocumented, no_cascade_delete option is now
deprecated.

Tony