I think changing when signals fire is bound to cause breakages for some apps, and of the worst variety because signals both deal with basic data integrity and are relatively opaque (I.e. debugging is a pain). Even if the current behavior isn't what we would choose given a blank slate, it can't realistically be changed.
On the other hand, supporting thus use case isn't impossible. Maybe we could add a "fire_for_subclasses" kwarg to the connect() method or something. That way concrete models can specify that they absolutely want their signals fired, and the resolution can be done at load time to avoid performance hits from isinstance calls. Best, Alex Ogier On Apr 12, 2012 2:59 PM, "Carl Meyer" <c...@oddbird.net> wrote: > On 04/12/2012 12:43 PM, Anssi Kääriäinen wrote: > > It is important that pre/post init signals will not get more expensive > > than they currently are. Even now they can give around 100% overhead > > to model.__init__(). And this is in a case where the currently > > initialized model has no signals attached at all - it is enough that > > _some_ model in the project has pre or post init signals attached. I > > don't believe signaling cost is severe for .save and .delete as those > > operations are doing much heavier work than __init__ anyways, but for > > init the cost is big enough already. If at all possible, make them > > cheaper. > > So this is an argument against firing the init signals multiple times, > for each superclass, but it's not an argument against changing the > signal framework to include superclass receivers, as proposed in #9318; > that would not change the performance characteristics for the > no-receivers situation. > > (I see that this choice also has implications for the performance > improvement patch in #16679, but it looks like we have a workable option > there either way). > > > In addition, just changing the signals to fire for every parent class > > is pretty much as backwards incompatible as it gets: imagine you have > > post_save signal which increments a counter in a related model on > > create (posts in a thread for example). You have also a proxy model, > > and you have attached the same signal to the proxy model, too, because > > that is what you have to do to get the signal fire when you save the > > proxy model. After the change you will get the counter incremented two > > times for create, and you have a data corrupting bug. This might not > > be a common pattern, but for example Django's use of pre and post init > > signals follows the pattern of attaching to each subclass individually > > and these signals would thus fire multiple times. > > Yes, this is similar to the audit-trail handler I mentioned, and I agree > that it is a significant backwards-compatibility problem for either option. > > So perhaps we do need the signal inheritance behavior to be opt-in when > connecting the signal handler. I think I'd like to see a deprecation > path so that eventually the inheritance behavior is the default, and you > have to opt out of it, as I think in most cases it's the desired behavior. > > Carl > > -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
