[Dbix-class] Order of operations in CascadeActions::delete

[Pedro Melo]

Hi,

On Apr 24, 2007, at 1:44 PM, Jess Robinson wrote:
> On Thu, 19 Apr 2007, Pedro Melo wrote:
>> looking at CascadeActions::delete (http://search.cpan.org/src/ 
>> JROBINSON/DBIx-Class-0.07999_02/lib/DBIx/Class/Relationship/ 
>> CascadeActions.pm), the code deletes $self and then goes on to  
>> delete the related objects. Shouldn't this be the reverse?
>>
>> If a database has FOREIGN KEYs statements with ON DELETE CASCADE,  
>> the second part will never find any elements to delete. Also, even  
>> if we don't have ON DELETE CASCADE at the database level, it makes  
>> more sense to me to first delete the related objects and only then  
>> delete the "parent" object.
>
> DBIC much prefers that you allow/setup the database to do the  
> delete-cascading, if it deleted the related objects first, and then  
> the main one, then DB-side would never kick in. Also if the DB rels  
> had ON CASCADE FAIL set, we'd never trigger it.
>
> The DBIC-side cascade is merely to paper over the cracks of  
> databases that don't support DB-side FK setting and so on.

First, I agree with you that cascade delete on the database side is  
probably best, and that the db-side cascading delete taking  
preference is documented in the Relationship.pm perldoc.

But allowing DBIC to perform the delete itself is useful when you  
have extra business logic attached to the delete action.

Besides, as a general rule, shouldn't child objects be destroyed  
before the parent?

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
Jabber ID: melo at simplicidade.org
Use Jabber!