Re: Deleting an object on the other side of a has_a

[prev] [thread] [next] [Date index for 2004/09/01]

On Wed, 2004-09-01 at 12:45, William McKee wrote:
> OK, let me see if I understand. In the after_update trigger, you would
> add code to see if $self->my_b was undef or empty then delete b. How
> would you know which b to delete if we've removed the reference?

Good point!  You would need a before_set_$column trigger to stash the
previous value in the object.  So, maybe it's all more complex than it's
worth. 

> Absolutely. Let me put it in the context of a might_have relationship
> where a might_have b. Say the user no longer wants liner_notes (to use
> the CDBI example). I need a way to delete the object. I think Peter's
> example along with your suggestion to update a before deleting b appears
> to be the best solution.

The only other solution I can think of would be to make b do a search
for all objects that point to it and update them to remove the
reference, which would be another sort of cascading delete.  The
has_many relationship already does something similar, but it deletes the
objects that point to it rather than just removing their references.

> In reviewing my code again, I see that I've really only skirted the
> issue. Instead of using the longer version that Peter showed, I'm using
> the following format:
> 
>   $a->my_b->delete();
> 
> I believe that this could introduce the referential integrity problem.

Looks like it to me.

> I'm going to change that one-liner to the following:
> 
>    my $b = $self->my_b;
>    $self->my_b(undef);
>    $a->update;
>    $b->delete;
> 
> Does that look right to you?

Yes.

- Perrin