[DBIx-Class-Devel] Re: [dbix-class] cascaded delete must delete relationships first (#27)

[Peter Rabbitson]

On Sat, May 25, 2013 at 09:03:22PM -0700, Brendan Byrd wrote:
> MySQL has commands for disabling FK checks

... and is supported by DBIC's with_deferred_fk_checks()[1] (which is a 
tad unmaintained[2] but works).

> ... We can't just say that we don't support cascade deletes when we 
> have a cascade_delete flag in the relationship.

We can if cascade_delete is declared a kludge that was a good idea at 
the time but definitely isn't these days. I know it is *my* fault this 
wasn't done yet in a public manner (i.e. deprecation etc). The scope of 
the problem with deprecating this bunch of suck is a bit larger, I am 
currently working out through a way to do it safely. urns out this isn't 
relevant to the discussion though, see below.

> Sure, the exception is documented, and yes, it's been in there 
> forever. But causing an exception for a fairly common use case is 
> still a bug

It is if you look at it this way. Resd below.

> especially when there isn't any way around it

Um... are you saying there is no way to write a project-wide cascading 
visitor that cals the deletes before DBIC does what it intended to 
do...? It is not *asy* to do it, but it sure isn't *impossible*

> Let's provide some answers instead of constantly shooting down his 
> suggestions.

I only shot down a particularly gnarly addition to the API, not the 
entire idea. In fact @joseds and @vanstyn are working on a critical part 
of infrastructure which will make this stuff much easier.

But now to the actual problem at hand: We currently have DBIC-side 
delete cascades which are *designed* to emulate RDBMS-side cascades. It 
is *not* a mechanism to *work around* RDBMS-side cascade restrictions. 
This ticket is proposing to make it one (either replace the old behavior 
or augment it).

Fusing these two concerns together "emulate RDBMS cascading delete 
triggers" and "avoid RDBMS cascading delete triggers" is dangerous from 
any API standpoint. Providing such mechanism in the core library (and 
thus hinting it's a good idea) is just irresponsible.

As such I am declaring "let's extend DBIC with a way to declare a 
relationship to delete the children first without asking" an absolute 
no-go, let's not waste time discussing it further.

The bigger picture however yields the problem which is worth solving: 
"Let's provide a canonical way to write a relationship visitor so it is 
easy to write any sort of pre/post trigger behavior in 20 lines and 
throw it on CPAN". This is something that is already being worked on, 
and which will become available very soon, possibly with 0.08251.

I believe this addresses the original problem elegantly without 
compromising further the coherency of the DBIC core. Note - I am not 
saying the current core state is especially coherent as it is, but 
that's no excuse to keep mudding down the API.

Cheers