On Jul 1, 2011, at 2:04 PM, Jeremy Dunck wrote: > What I mean is, the scenario you described doesn't affect me, because > flushing rather than deleting specific keys would be fine to me. I > guess, generally, I meant to point out that presuming your scenario > applies to the community is a bad point to start from. More to the > point, a solution for core should be either an extension point, or a > solution that all can agree is good commonly.
Thanks for expanding on this point, I understand now. Just to clarify, I don't presume my scenario is what the community wants -- like you I actually don't care that much about calling cache.flush() where I run tests. I just wanted to throw out some concrete ideas for requirements so that there was a starting point for discussion. That said, I am certainly still arguing for this requirement. I believe as a general principle that a testing framework should always return the system under test to the state it was in prior to the run. Calling cache.flush() violates that principle -- and of principle concern to me, it flushes your *entire* cache. That means if someone executed tests in production it could kill an entire cache, a situation which could be slightly annoying or a horrific headache depending. Of course, if no one else agrees with me that this is a worthy principle for Django tests then I won't waste anyone's time by undertaking a patch :) > What I meant to point out is that the test process, which is doing the > book-keeping, may not have visibility to all of the key cleanup that's > needed; a common use case of that is that celery (an out-of-process > task queue commonly used with Django) does some work and pushes some > data into cache in response to an async. I'm arguing that if you want > a clean workspace, how you get there depends on both how keys are > generated and what the cache backend is. Okay, understood for the most part. It's hard for me to tell without having gotten my hands dirty yet how much that will matter in the context of running tests. But to me it's kind of like sending email. There are plenty of ways to send mail from Python, and your application might very well send actual email out during a test run if e.g. you use an alternate email API of some kind. Django's test suite makes no promise that *no* email will be sent when you run tests, it only promises that if you use the standard email backend API it'll be replaced with a dummy backend -- and that no email will be sent if you use Django's provided API. Likewise, I'd be doubtful that we could guarantee with certainty that running the tests would not affect the cache at all. What I would hope to accomplish was that if your application called cache or get_cache, it would get a modified backend that deleted any entries you inserted after each and every test run. If your system touches a cache via other means then you're sort of on your own (which of course is the status quo right now for all of the cache). Just to reiterate, I really do appreciate your taking the time to get back to me with this feedback. Thanks! Cheers, Jim -- 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.
