It's not unusual to have a setup like this: development box -> test box -> production box
The test box is a clone of the production box, as much as you can make it so. No reason why it couldn't be a virtual machine, but it has to be there to prevent surprises due to different patch/version levels of the various packages in the system. On Thursday, June 7, 2012 3:48:00 PM UTC-4, Derek wrote: > > Ah, it seemed to me this is just a development environment and thus you > wouldn't need this feature in production? > > On Thursday, May 31, 2012 2:47:51 PM UTC-7, Jonathan Lundell wrote: >> >> On May 31, 2012, at 2:32 PM, Derek wrote: >> >> If you're blowing away your database, why don't you clear memcached when >> you blow away your database? I don't see how this is a web2py issue. >> >> >> One possible reason: web2py (and in particular my application) aren't >> necessarily the only memcached clients on the machine. >> >> Regardless, it's more a puzzle than an issue. I can certainly clear my >> caches manually, and that's in fact what I do now. But if there *were* a >> straightforward way to detect web2py restart from inside an app, that'd be >> handy in this particular case. >> >> >> On Wednesday, May 30, 2012 7:10:13 PM UTC-7, Jonathan Lundell wrote: >>> >>> I've got an application that uses memcached. I'd like to recognize when >>> web2py gets restarted (mod_wsgi, fwiw) so I can flush my cache. No doubt I >>> can figure something out, but I'm sure I must be missing something obvious. >>> (My motivation: in my development environment, I sometimes blow away my >>> database when installing and starting a new copy of the app, and things get >>> confused when the cache is still holding data from the earlier run.) >> >> >> >>
