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
-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
> fu
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 custom delete methods. Which i
"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 a
> 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).
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 wrote:
> Did my last p
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
django-developers+
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 grou
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 the delete method on each fo
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, send
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
11 matches
Mail list logo