[Dbix-class] Cascade deletes

[Bill Moseley]

On Sat, Mar 6, 2010 at 3:59 AM, Peter Rabbitson
<rabbit+dbic at rabbit.us<rabbit%2Bdbic at rabbit.us>
> wrote:

> > I notice that DBIC does a select to find the related rows (i.e. in the
> > Cd table when looking for rows to cascade delete).   Is there a reason
> > that's done instead of just deleting directly?
> >
> > INSERT INTO artist ( label, name) VALUES ( ?, ? ): '1', 'test aritst'
> > INSERT INTO cd ( artist) VALUES ( ? ): '25'
> >
> > DELETE FROM artist WHERE ( id =3D ? ): '25'
> > SELECT me.id <http://me.id>, me.year, me.name <http://me.name>,
> > me.artist FROM cd me WHERE ( me.artist =3D ? ): '25'
> > DELETE FROM cd WHERE ( id =3D ? ): '54'
> >
> > Why not just delete from cd where artist =3D 25?
>
> Because this will not invoke the various triggers that could be hidden
> in lower classes (at the very least if you delete from an rs CDs then
> dbic will not know to delete from Tracks).
>

The delete Isn't it a recursive process?  Or are you saying the select is
important for invoking the triggers?

Also, I'm curious why the cascade deletes happen last instead of first?
That is why not work where $artist->delete first deletes all the artist's
CDs (which first deletes all the CD's tracks, and so on), then finally
deletes the artist.  That way there's no time when a row in one table (e.g.
CD table) is referencing a deleted row (e.g. in Artist).

I'll use Pedro's suggestion to globally disable cascades.

Thanks for the help and explanations,


-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100306/385=
ca908/attachment.htm