Re: Feature proposal: models.CALL_DELETE or effective equivalent

Hi Carl, Thanks for the reply. My guess is that adding a new, optional Meta argument, (e.g. ``call_delete_on_fk_delete = True``) would be much simpler to implement. I used ``on_delete`` to make it easy to understand what I'm asking for, though if it is possible to achieve this way, I'd be willing

Re: Feature proposal: models.CALL_DELETE or effective equivalent

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2011 08:31 AM, Yo-Yo Ma wrote: > While I agree that signals allow for neat decoupling, they aren't as > DRY or quick as a simple field kwarg. Imagine you have 8 models that > have custom delete methods. Which is easier: A) avstracting the >

Re: Feature proposal: models.CALL_DELETE or effective equivalent

On Dec 4, 10:46 pm, Justin Holmes wrote: > "hacks, signals, and/or patches" > > One of these things is not like the other While I agree that signals allow for neat decoupling, they aren't as DRY or quick as a simple field kwarg. Imagine you have 8 models that have

Re: Feature proposal: models.CALL_DELETE or effective equivalent

"hacks, signals, and/or patches" One of these things is not like the other. The signals framework is made for precisely for cases like the one you describe. Why do you compare it to hacks / patches? Your signal can be utterly DRY and you can write unit tests for it (although, if you are using

Re: Feature proposal: models.CALL_DELETE or effective equivalent

> Or is your main objection having to branch against the specific Simply put, there should be an *optional* way to ensure a model's *explicitly* defined delete behavior is honored without having to write hacks, signals, and/or patches of any kind (ie, make it DRY, and therefore less error-prone).

Re: Feature proposal: models.CALL_DELETE or effective equivalent

Doesn't using the pre_delete signal accomplish this? Or is your main objection having to branch against the specific models, leading to the coupling you are talking about? It surely solves the monkey-patching problem, though, no? On Sun, Dec 4, 2011 at 3:14 PM, Yo-Yo Ma

Re: Feature proposal: models.CALL_DELETE or effective equivalent

Did my last post answer the question you had, Adrian? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to

Re: Feature proposal: models.CALL_DELETE or effective equivalent

Adrian, My apologies, what I'm meaning is: on deletion of the restaurant, rather than issuing a bulk SQL deletion of the Table instances, call the delete method for each. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this

Re: Feature proposal: models.CALL_DELETE or effective equivalent

On Thu, Dec 1, 2011 at 11:26 PM, Yo-Yo Ma wrote: > My proposal is to add a new on_delete=models.SET-ish feature (or a new > kwarg altogether) which would, when specified, cause the parent > object's delete to loop through an iterator of the related instances > and call

Re: Feature proposal: models.CALL_DELETE or effective equivalent

My "table" typo was intended to be the "restaurant" of a Table model (it's late :) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group,

Feature proposal: models.CALL_DELETE or effective equivalent

It's quite a common practice to customize a model's delete method. This normally leads to the recommended practice of "just loop through instances and delete each in lieu of using QuerySet.delete". That works well, within limited context. However, when you've got a model that's high up in the food