[Dbix-class] Cascade deletes
Peter Rabbitson
rabbit+dbic at rabbit.us
Sun Mar 7 00:14:08 GMT 2010
Bill Moseley wrote:
>
>
> On Sat, Mar 6, 2010 at 3:59 AM, Peter Rabbitson <rabbit+dbic at rabbit.us
> <mailto: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 = ? ): '25'
> > SELECT me.id <http://me.id> <http://me.id>, me.year, me.name
> <http://me.name> <http://me.name>,
> > me.artist FROM cd me WHERE ( me.artist = ? ): '25'
> > DELETE FROM cd WHERE ( id = ? ): '54'
> >
> > Why not just delete from cd where artist = 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?
If you look at the code in DBIx::Class::Relationship::CascadeActions
it will all make sense (the SELECT-causeing call is clearly visible)
> 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).
Because if (like in your case) dbic-side delete cascading is enabled,
we still want to give the database a chance to invoke its own triggers.
This is why first the CDs are deleted, and then if cascade is enabled -
anything else (if anything is left at all).
In the meantime we now correctly wrap delete/update in transactions
if deemed necessary: http://dev.catalystframework.org/svnweb/bast/revision?rev=8921
Cheers
More information about the DBIx-Class
mailing list