On Jun 10, 2012, at 11:42 PM, Anthony wrote: > What I am hearing is that even the 'reload routes' button is not safe > to use on a busy server. > > Yes, but it's a fairly general problem, not specific to the web2py rewrite > system. Let's say someone loads a page from your projectX2011 app and leaves > the page open for a while. While they have the page open, you redirect all > /projectX links from projectX2011 to projectX2012. If the user then clicks > one of the links on the page (or if the page makes an Ajax request), the new > request will go to projectX2012, even though the original page was from > projectX2011. This is a problem whether you use symbolic links, web2py > rewrite, Apache mod_rewrite, or any other method. The issue could probably be > addressed, but it would get tricky (maybe track IP addresses and route > requests to the old app if from an IP address that has made a request within > some earlier window of time).
What all those mechanisms have in common is that they effectively redefine the meaning/referents of URLs. One could imagine workarounds, fairly elaborate, for the routing case—say having something in the session to determine the routing logic to be used. That would be either impossible or much more difficult with links or mod_rewrite. More practical, I think, to quiesce the site for a while. > > I've created an issue > http://code.google.com/p/web2py/issues/detail?id=847 with some > potential/suggested minor content changes. > I doubt they match the voice of the rest of the document, but > hopefully some concrete suggested wording is better than none. > > Note, routes.py is not a module that gets imported (the file gets read and > executed), so track changes shouldn't have any effect on it. Also, I wouldn't > quite say that reloading routes while web2py is running isn't supported (in > fact, the problem noted above holds even if you stop the webserver briefly, > so by that logic, reloading routes would never be supported). > > Anthony
