Awesome feedback, thanks. On Jul 1, 2011, at 10:01 AM, Jeremy Dunck wrote:
> Well, I think you forgot all the other low-level cache options, like > .incr, .add, etc.? Yep, forgot those so they would conceivably need to be tracked. > > 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? > > 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. > > 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 know what you mean about it being fiddly, but I'm kind of envisioning something not all that different from what goes on with Template.render() settings.EMAIL_BACKEND, or the database backends during test setup and teardown. The bookkeeping required would in truth be nothing more than a set() where you add keys. The monkey patching would entail nothing more than a line to add the passed keys to that set and then a call to the original function. I'm just not sure it's much more fiddly than the fiddling we already do for those examples is what I'm saying. 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. Anyhow thanks once again for the feedback and the critical thoughts. -- 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.
