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
signature.asc
Description: OpenPGP digital signature
