[Dbix-class] bug in delete_all: CascadeActions::delete removes parent before children

[Noel Burton-Krahn]

Well, delete_all can't work the way its currently implemented if your
database enforces referential integrity, and if you do cascading
deletes with triggers, you don't need delete_all at all.  If that's
the way you want to leave things, I'd suggest removing delete_all
altogether.  I always enforce referential integrity myself, and it is
handy to have a function that will recursively delete dependent
objects (in the right order, of course), so I would find it more
useful to keep delete_all, but fix it so it works with referential
integrity.

It would also be nice to get the ambiguous select thing fixed because
that's bitten me a couple of times before too.  Where does the SQL
construction happen?


~Noel



On Sat, Oct 25, 2008 at 4:16 AM, Jess Robinson
<castaway at desert-island.me.uk> wrote:
>
>
> On Fri, 24 Oct 2008, Noel Burton-Krahn wrote:
>
>> DBIx's cascading delete_all (in DBIx::Class::ResultSet) it broken,
>> because it deletes the parent table before it deletes the children.
>> The database will throw a referential integrity exception when the
>> parent is deleted before the children.    I've attached a test program
>> below.  Here's a fixed version in
>
> This is intentional. DBICs cascade delete / relationship support deletes in
> this fashion so that it does not get in the way of your database itself
> doing it.
>
> Either: Let DBIC do the deleting in this way for you, or turn off DBICs
> cascading and let your database do it.
>
> Jess
>
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
>