On Fri, Jul 1, 2011 at 12:27 PM, Jim Dalton <jim.dal...@gmail.com> wrote: > Awesome feedback, thanks. > > On Jul 1, 2011, at 10:01 AM, Jeremy Dunck wrote: > ... >> If I were to do this, I wouldn't have cache shared between tests or >> environments, so I'd be tempted to use flush. > > I'm not totally sure if I'm following you on this point?
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. >> Rather than "test_" and bookkeeping on key names, the key prefix was >> the hostname + timestamp from the beginning of the run, so that test >> keys would never collide? > > What I like about this idea is it avoids the bookkeeping and monkey-patching > nonsense. What I don't like about it is that it feels like you could > potentially be adding a lot of junk to your cache. A test run might end up > hitting it with many values, each unique. A requirement I'm sort of working > with in my mind here is that the cache returns to the "pristine" state it was > in prior to the test run. > That's true about collecting garbage. It would matter for filesystem cache, I guess. I don't much care about that, since cache for me is either memcache (which dumps LRU entries) or dummy. As far as returning to "pristine", hmm. If that's the case, I think you're arguing for setUp and tearDown to do that setup. >> Or, what if we just had hooks called from setUp and tearDown, either >> NotImplemented methods, or signals? >> >> Book-keeping with monkey-patched methods sounds fiddly to me; consider >> the case where celery pokes keys in, but our bookkeeping doesn't know >> about it? > ... > I"m not quite sure what you mean about celery poking keys in. Maybe you can > elaborate a bit? To be clear I'm not sure we could keep the actual underling > cache entirely pristine if you were using it in different ways from different > systems; the goal would really be to ensure calls using the cache backend API > are rolled back with every test. 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. -- 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.
