On Sun, 2009-03-29 at 16:28 -0700, Oliver Beattie wrote: > Hey Everyone, > > I just wanted to poll opinion on a feature request I'm considering > posting a ticket for (and obviously write a patch for). Basically, I > want the cache framework to send signals whenever it interacts with > the cache (things like cache_hit, cache_miss, cache_set, > cache_deleted).
We're generally against new signals without a really strong use-case and no other way to do something. > > I know this is probably something only a small proportion of users > would find useful, but the use case I've come across is when it is > necessary to set values in a real cache as part of a unit test on a > BuildBot box (or whatever), and the values need to be kept track of so > they can be removed from the cache in the test cleanup. Particlarly adding signals that are *only* going to help testing but impose an overhead for everything seems like a bad idea. I'm going to claim the answer here is to restructure your tests so that you don't have to use any production cache system and can just restart (and hence flush) the cache at the end of the test. Alternatively, write a cache backend that wraps your preferred choice of an existing backend to track stores, etc, and then clean them up using that list. I'm not convinced new signals are needed here. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
