On 28/03/10 00:01, Russell Keith-Magee wrote:
Cache invalidation is a reasonably compelling case for pre-signals; if you invalidate a cache on the post-signal, there is a small window between having modified the m2m and the cache being flushed. In that window, any operation hitting the cache will see the m2m relations still existing, but any operation that actually hits the database will disagree. It's a really small edge case, but that's the class of Heisenbug that is a pain to find in the wild.
Surely there's a Heisenbug for the opposite case, though; you invalidate the cache, someone else hits a page, the M2M gets re-cached in its current (still original) state, and then finally the M2M relation change goes through. You now have an incorrect cache that's not going to be invalidated any time soon.
However, as you note, any raw SQL activity will probably need to happen in the post signal, so that's probably enough of a reason to include pre and post signals.
I'm strongly *for* including pre- and post- for all three; it just makes sense to include these as options, considering they are elsewhere, and I'm not convinced that the hit of an empty signal is that significant (there's a function call, an assignment, and an if statement); as a percentage of runtime, it seems very small (someone feel free to prove me wrong, though!)
Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
