[ZODB-Dev] Re: trigger loading a Persistent's attributes
Simon Burton wrote: On Sun, 28 Jan 2007 19:00:33 +0100 Dieter Maurer [EMAIL PROTECTED] wrote: Simon Burton wrote at 2007-1-27 15:18 -0800: I have a Persistent object, however, its attributes only get loaded from the storage when I request a specific attribute. Problem is, I don't know the names of the attributes necessarily. I was trying to just query the __dict__ but this does not trigger a load. Is there another way to do this ? Accessing (almost) any attribute (even a non existing one) will load the object. There are a few exceptions: attributes starting with _p_ or _v_. Yes. I looked at the dir function, it seems that when it accesses the __members__ attribute this triggers a load. This is ZODB-fu. So be it. Broadly, if you just request an object (rather than a method or attribute), then the ZODB returns a 'ghost' object. The ghost object is transformed into the real object once a method or attribute are used. If you have a persistent object that you think is a ghost, you can call _p_activate() on it. That will load __dict__ and turn it into the full object for you to use as you want. At least, that's what I've found - if this is wrong then someone should speak up! Miles ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Invalidating caches for module refresh doesn't seem to work
On Jan 29, 2007, at 5:46 PM, Philipp von Weitershausen wrote: After refreshing a product, Zope 2 uses the following stanza in App.RefreshFuncs.autoRefresh() to let the ZODB know that it should invalidate its pickle caches: ... refresh products from ZODB import Connection Connection.resetCaches() transaction.commit() jar._resetCache() transaction.begin() That is really weird code. It looks very brittle. That way, persistent objects will use the newly reimported classes instead of continuing to use the old, no longer current classes. I suppose that was the intent. For grok I tried to implement the same mechanism and copied that code almost verbatimly, only to find out it doesn't seem to work. Persistent objects will still be instances of the classes that should have been thrown away during the re-import of modules. Testing product refresh with both Zope 2.9 and 2.10 produces errors for me while Zope 2.8 works, which leads me to the assumption that a cache invalidation bug was introduced after ZODB 3.4. Is anybody else seeing this? The way that connections were managed changes quite a bit in 3.4. I'm a bit surprised nobody else has complained about this so far... Maybe people finally stopped using product-refresh because it doesn't work reliably. Help with tracking this down would be greatly appreciated. Shane originally wrote this. Maybe he could help out. I'm not interested myself. In fact, I'l be happy to see this code get ripped out. If it stays in it needs a doctest to prevent future regression and to explain how to use it, including what it's semantics and limitations are. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] Re: Invalidating caches for module refresh doesn't seem to work
Jim Fulton wrote: On Jan 29, 2007, at 5:46 PM, Philipp von Weitershausen wrote: After refreshing a product, Zope 2 uses the following stanza in App.RefreshFuncs.autoRefresh() to let the ZODB know that it should invalidate its pickle caches: ... refresh products from ZODB import Connection Connection.resetCaches() transaction.commit() jar._resetCache() transaction.begin() That is really weird code. It looks very brittle. That way, persistent objects will use the newly reimported classes instead of continuing to use the old, no longer current classes. I suppose that was the intent. For grok I tried to implement the same mechanism and copied that code almost verbatimly, only to find out it doesn't seem to work. Persistent objects will still be instances of the classes that should have been thrown away during the re-import of modules. Testing product refresh with both Zope 2.9 and 2.10 produces errors for me while Zope 2.8 works, which leads me to the assumption that a cache invalidation bug was introduced after ZODB 3.4. Is anybody else seeing this? The way that connections were managed changes quite a bit in 3.4. I'm a bit surprised nobody else has complained about this so far... Maybe people finally stopped using product-refresh because it doesn't work reliably. What do I have to do to make it work reliably? I'd like to avoid having to restart all of Zope. (Note that this is grok on Zope3, not necessarily Zope 2). Help with tracking this down would be greatly appreciated. Shane originally wrote this. Maybe he could help out. I'm not interested myself. In fact, I'l be happy to see this code get ripped out. If it stays in it needs a doctest to prevent future regression and to explain how to use it, including what it's semantics and limitations are. So, are there any alternatives that let me refresh modules w/o server restarts AND make the ZODB aware of this? Would closing and reopening the database altogether be an option? I would assume it would leave the connections that other threads have to the database in a funny state, but I don't understand a whole lot about ZODB internals so I'm just guessing. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] Re: Invalidating caches for module refresh doesn't seem to work
On Jan 30, 2007, at 11:12 AM, Philipp von Weitershausen wrote: Jim Fulton wrote: On Jan 29, 2007, at 5:46 PM, Philipp von Weitershausen wrote: After refreshing a product, Zope 2 uses the following stanza in App.RefreshFuncs.autoRefresh() to let the ZODB know that it should invalidate its pickle caches: ... refresh products from ZODB import Connection Connection.resetCaches() transaction.commit() jar._resetCache() transaction.begin() That is really weird code. It looks very brittle. That way, persistent objects will use the newly reimported classes instead of continuing to use the old, no longer current classes. I suppose that was the intent. For grok I tried to implement the same mechanism and copied that code almost verbatimly, only to find out it doesn't seem to work. Persistent objects will still be instances of the classes that should have been thrown away during the re-import of modules. Testing product refresh with both Zope 2.9 and 2.10 produces errors for me while Zope 2.8 works, which leads me to the assumption that a cache invalidation bug was introduced after ZODB 3.4. Is anybody else seeing this? The way that connections were managed changes quite a bit in 3.4. I'm a bit surprised nobody else has complained about this so far... Maybe people finally stopped using product-refresh because it doesn't work reliably. What do I have to do to make it work reliably? I'd like to avoid having to restart all of Zope. (Note that this is grok on Zope3, not necessarily Zope 2). There is nothing you can do. Bonus: Zope 3 makes it even harder for reasons that have nothing to do with ZODB. Help with tracking this down would be greatly appreciated. Shane originally wrote this. Maybe he could help out. I'm not interested myself. In fact, I'l be happy to see this code get ripped out. If it stays in it needs a doctest to prevent future regression and to explain how to use it, including what it's semantics and limitations are. So, are there any alternatives that let me refresh modules w/o server restarts AND make the ZODB aware of this? Would closing and reopening the database altogether be an option? I would assume it would leave the connections that other threads have to the database in a funny state, but I don't understand a whole lot about ZODB internals so I'm just guessing. The reliability problem isn't with ZODB. The cache-refresh thing can be made to work there, if anyone cares. (Honestly, I'd rather see the feature go away to make ZODB a little bit simpler.) The problem is with module globals that are outside the scope of ZODB. The problem with product refresh is that it seems to work much of the time. When it doesn't work, people get really weird bugs that they waste a lot of time chasing, forgetting that module reload is involved. Python modules were not designed to be reloadable. If you want to change that, I suggest taking that up on the Python 3000 list. (Maybe someone already has. Regrettably, I don't have time to watch that.) Period. ZODB appears to provide a clever way to get around some of the inherent module-reload problems, but it only provides a partial solution. My advice is to focus on making restarts faster. But that discussion should happen elsewhere, not on the ZODB-dev list. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Re: Invalidating caches for module refresh doesn't seem to work
Jim Fulton wrote: Python modules were not designed to be reloadable. If you want to change that, I suggest taking that up on the Python 3000 list. (Maybe someone already has. Regrettably, I don't have time to watch that.) I follow it pretty well and don't recall that being discussed. -- Benji York Senior Software Engineer Zope Corporation ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] ZODB 3.6 or 3.7b3?
Hi, I'm starting a new ZODB based project from scratch. Which of these two versions should I use? Is 3.7b3 ready for production use? Thanks. [ D A V I D G O U L D ] www.davidgould.com___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev