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

[Peter Rabbitson]

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
> 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.

You are missing the simple fact that the same codebase (dbic) has to
work properly on schemas with referential integrity enforced with
deletion triggers.

What you are suggesting will go like this:

1) You call delete_all
2) You traverse the entire relationship chain, and start calling delete
on the resulting three backwards, depth first.
3) By the time you get to the main row that you wanted to delete_all in
the first place, it runs a trigger which is supposed to run some
statistics on the rows the ref_integrity was supposed to delete - epic
fail: they are not there anymore.

In any case I am not entirely sure what your problem is. If you have
referential integrity enforced, and have proper ON DELETE xxx clauses
set - how is it that (quoting your original mail): "The database will
throw a referential integrity exception when the parent is deleted
before the children". Smells like a misdesigned schema to me.

> 
> 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?
> 

Can you rephrase this second issue you are talking about, without
referring the the first one (which is ENOPROBLEM).