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: [EMAIL PROTECTED]
Use Jabber!
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
