Christian Theune ct at gocept.com
Tue Mar 6 11:02:44 EST 2007


I'm working on a better Zope 2 product refresh mechanism right now and
compared that to what you did here.

Guido van Rossum came up with a good approach that works a lot better in
the context of ZODB applications as he doesn't unload the existing
module, but imports the module again into a new namespace and does
surgical operations to apply code updates in-place and keep references

I'm also implementing a rather gross approach on refreshing ZCML by just
simply emptying the global site manager and telling Five to load_site()
again. All in all this seems to work quite well. 

I do have to provide a couple of very gross hacks though that I'm
researching by using this on a large site with many products.

If you want to look at the code, check launchpad.net/refreshng

(The code is very gross right now as I'm still in the 'getting it right'


Am Dienstag, den 30.01.2007, 00:21 +0100 schrieb Philipp von
> At the snow sprint I took a first shot at module reload w/o server 
> restart: http://mail.zope.org/pipermail/checkins/2007-January/006059.html
> There are several issues to be solved yet, especially one with the ZODB. 
> It seems that it currently makes the re-import of Persistent subclasses 
> impossible because persistent objects seem to cling to the old classes 
> instead of the refreshed ones.
> Other than that I can report that reload actually works. The algorithm 
> that checks for file modification times also seems to be relatively fast 
> and shouldn't slow things down too much, especially when the files have 
> been recently touched anyway. Hitting the frontpage of grokwiki I 
> couldn't measure a significant deviation with and without autorefresh 
> enabled.
> That brings me to a question: It should be possible to disable 
> autorefresh. What would a sensible switch be? Zope3's developer-mode 
> (like Zope 2 uses debug-mode)? The problem with that is that it's not 
> enabled by default (although we could do that in grok). Note that I 
> don't think it makes any sense to allow or disallow the (auto)refresh 
> only for specific moduels or packages. Either we dump and reload 
> everything that's been grokked, or we don't. Anything else is going to 
> cause headaches, e.g. when you have subclasses of refreshed classes 
> (they aren't going to see the refreshed classes).
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20070306/f3700355/attachment.bin

More information about the Grok-dev mailing list