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

[Jess Robinson]

On Sat, 25 Oct 2008, Noel Burton-Krahn wrote:

> 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

If your DB enforces referencial integrity, then it also has a mechanism 
for cascading deletes. If you wish to turn on one but not the other, you 
cannot use DBIC with your database, it's as simple as that.

We need to allow databases to do the cascade themselves, (which they won't 
if we reverse the delete the way you suggest), and we also need to support 
databases that don't do cascading. That's why the code is as it is, and 
that's how it will stay.

Unless you can come up with a way to allow both of those, AND your 
"integrity on but no casacding" scenario.

> 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 wotks fine, just not the way you are expecting, with only some DB-side 
bits turned on.

Jess